We all TOLD YOU this would happen. This is what happens when you use a UNIX wannabe cobbled together by weekend hobbyists, instead of using an industrial strength OS like Windows or OSX that is rigorously crafted by professional coders.
Any statically linked executable you start should have no problem seeing "LD_PRELOAD" variables set in environments or the shared object files they are pointing to.
Sounds way less "stealthy" than those "trust zone" or UEFI based viruses that exploit CPU's/BIOS's malware-helping features.
I always see this on these, "OMG LInux malware" news items. Some article gets posted about some new malware variant which targets Linux-based servers/OS's and then, buried somewhere deep in the article, you finally see a part of the story which seemingly never makes the headline: for the malware to be effective some epic stupidity has to occur (root login, port 22 open, or, in this case, certain config variables set where they can easily be spotted even before compi
Furthermore, LD_PRELOAD mischief is not exactly new. It's why (at least once upon a time) a number of the admin tools were always static linked and kept in/sbin.
It's also part of the reason Alt-SysReq on the console can be used to get a dump of running processes direct from the kernel.
Failing all of that, booting a rescue disk (or RO image) can be used to examine the system free of the PRELOAD.
Unless I've lost my mind, they seem to wave their hands and say, "The attackers set LD_PRELOAD..." as if someone amok javascript process in your browser can accomplish this task.
For this to be worth a shit, it needs to be set as root (Linux dynamic linker will not LD_PRELOAD for an escalated process) and it needs to be done for each and every process spawned by your init. Contained as any user-account is pointless.
Otherwise, it's rather trivial to detect.
We all TOLD YOU this would happen. This is what happens when you use a UNIX wannabe cobbled together by weekend hobbyists, instead of using an industrial strength OS like Windows or OSX that is rigorously crafted by professional coders.
Sounds way less "stealthy" than those "trust zone" or UEFI based viruses that exploit CPU's/BIOS's malware-helping features.
Wish I had mod points, you'd get them all.
I always see this on these, "OMG LInux malware" news items. Some article gets posted about some new malware variant which targets Linux-based servers/OS's and then, buried somewhere deep in the article, you finally see a part of the story which seemingly never makes the headline: for the malware to be effective some epic stupidity has to occur (root login, port 22 open, or, in this case, certain config variables set where they can easily be spotted even before compi
^THIS!
Furthermore, LD_PRELOAD mischief is not exactly new. It's why (at least once upon a time) a number of the admin tools were always static linked and kept in /sbin.
It's also part of the reason Alt-SysReq on the console can be used to get a dump of running processes direct from the kernel.
Failing all of that, booting a rescue disk (or RO image) can be used to examine the system free of the PRELOAD.
For this to be worth a shit, it needs to be set as root (Linux dynamic linker will not LD_PRELOAD for an escalated process) and it needs to be done for each and every process spawned by your init. Contained as any user-account is pointless.
Otherwise, it's rather trivial to detect.
I'm less interested in abuse of LD_PRELOAD, as I