This is the same company that wasn't aware that LD_PRELOAD has been in use since the 90's in their last post. Here is that unique method of hijacking execution flow using /etc/ld.so.preload, 20 years ago: <a href="https://seclists.org/incidents/2002/Jan/86" rel="nofollow">https://seclists.org/incidents/2002/Jan/86</a>. None of this is unique or novel, including replacing the loader. LD_PRELOAD rootkits have severe drawbacks (which are not an issue for eBPF rootkits).
Would love to see these researchers comment on whether their new favourite exploit can bypass selinux or other MAC systems. I know a lot of lazy admins don't bother but if selinux will protect you, wouldn't you want to know?
Avoid using Glibc or patch-out LD_PRELOAD unless you need it. I don't mean as a response to this one threat but in general it seems to be the go to hooking mechanism. With this measure and signed kernel module loading enforcement with secureboot you can make it more hostile for untargeted malware to succeed in persisting or installing a rootkit.
Enjoyable article.<p>I am fairly confident that this rootkit would be detected by rkhunter, but possibly only when the adversary is logged into the machine, as the malware hides the pids and network ports associated with their ssh connection.
Fun fact: essentially all of the described exploits are entirely dependent on dynamic linking, which is something no sane modern OS should support. Thanks Drepper!
Nice read, I wonder how this was detected though.
Did it trigger any alarms on the infected machine? Was a firewall or specialized traffic inspection involved?