Hacker News Reader

Comment by eridius | Hacker News Reader

How is it a backdoor? System services don't typically source the user's bash profile before running, and even if they did, they don't run from attacker-controlled directories anyway. At best you could compromise someone by tricking them into cd'ing into a folder you provided, but that's not something that would generally be called a "backdoor". And if you can get them to run your install script, you've already "compromised" them anyway and LD_LIBRARY_PATH is completely unnecessary.

View on HN

> And if you can get them to run your install script

If your script is obviously malicious then you're reducing your chances. Such a change could seem innocuous[0], then, cloning a repo containing a so file in the middle of a long list and cd'ing would trigger payload execution. Distributing the maliciousness by chaining innocuously looking actions is both effective at bypassing human logical analysis and plausibly deniable (up to a point).

[0]: http://underhanded-c.org

If you clone a repo and cd into it, that's because you're going to actually do something in there. An install script that clones a repo, cd's into it, and then does nothing is extremely suspicious. But a script that clones a repo, cd's into it, and runs `make install` isn't particularly suspicious, so once again, there's no need for LD_LIBRARY_PATH.

with several browsers happy to automatically download whatever is provided to them, making a user download a libblahblah.so is relatively easy, and unless the user was aware of the ramifications of just even having such a file in a folder, might ls, cat, grep, etc in that folder like they do any other day

However, most of the latest versions of the mainstream browsers now intentionally avoid writing out such files to the downloads folder unless the end user specifically OKs it (due to situations like this!)

It's a plausibly-deniable backdoor on top of LD_LIBRARY_PATH, just to clarify. As in - oops, I added the colon at the end, or if the LD_LIBRARY_PATH was programmatically generated, a sloppy loop can clearly do that...and now you're stuck with unexpected behavior which, while not directly unsafe, can be coopted in a nefarious manner. The $PWD behavior is niche, unexpected and likely to be missed in an audit. If you have software that relies of LD_LIBRARY_PATH and you distribute the OS, I'd change ld.so to avoid the $PWD behavior.

It's not plausible.

It's a very unreliable attack vector, but what makes it completely pointless is in order to even set it up, you already need permission to edit the user's bash profile, and if you can do that, then you don't need LD_LIBRARY_PATH.

Reply on news.ycombinator.com