Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Torch broke ls and made me vulnerable

joshumax.github.io

Post reply on HN
Print view View original

31–38 of 38 posts

Re: How Torch broke ls and made me vulnerable

#31

Post by eridius »

lloeki wrote: post #19
eridius wrote: post #10

Earlier quoted context omitted.

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 "compr…

> 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 d…

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.

Re: How Torch broke ls and made me vulnerable

#32

Post by Spivak »

pjc50 wrote: post #30
catdog wrote: post #17

Earlier quoted context omitted.

This nice and clean solution is too little known I think. Far better than shipping shell scripts which are very hard to get right and most application developers are not shell scripting experts.

RPATH is very nice, but it's a huge pain to set in Makefiles because you have to reliably escape the "$ORIGIN"

(Don't do this) You could patch the binary after compilation with elfpatch.

Also,

test:

  echo "\$$ORIGIN"
outputs $ORIGIN. $$ translates to a literal dollar sign. \ escapes the dollar sign in the shell.

Re: How Torch broke ls and made me vulnerable

#33

Post by andreiw »

eridius wrote: post #10
andreiw wrote: post #3

you know, that's a pretty good plausibly-deniable backdoor, if you think about it... sounds like a pretty good thing to disable in ld.so...

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 "compr…

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.

Re: How Torch broke ls and made me vulnerable

#34

Post by eridius »

andreiw wrote: post #33
eridius wrote: post #10

Earlier quoted context omitted.

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 "compr…

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 ha…

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.

Re: How Torch broke ls and made me vulnerable

#35

Post by JadeNB »

IshKebab wrote: post #25

Ha, shitty text-based configuration systems strike again. Ask yourself if this could have happened with Windows 10's PATH editor.

> Ask yourself if this could have happened with Windows 10's PATH editor.

Yes …? Well, I dunno; I don't know how Windows 10's PATH editor works. Nonetheless, the issue seems to be with magic interpretation of special configuration options, not with how those configuration options are entered. (Note also that the configuration was done programmatically, not by the user, so that there would have to be some kind of parse–deparse step anyway.)

Re: How Torch broke ls and made me vulnerable

#36

Post by binarycrusader »

Spivak wrote: post #32
pjc50 wrote: post #30

Earlier quoted context omitted.

RPATH is very nice, but it's a huge pain to set in Makefiles because you have to reliably escape the "$ORIGIN"

(Don't do this) You could patch the binary after compilation with elfpatch. Also, test: echo "\$$ORIGIN" outputs $ORIGIN. $$ translates to a literal dollar sign. \ escapes the dollar sign in the shell.

You can use elfedit instead, but really, it's not that much of a pain to just do it right in the first place.

Re: How Torch broke ls and made me vulnerable

#37

Post by emmelaich »

djsumdog wrote: post #11
anderskaseorg wrote: post #5

How to safely prepend a directory to a PATH-like variable (in any POSIX-compliant shell): export LD_LIBRARY_PATH=/opt/whatever/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH} Pull request sent to https://github.com/torch/distro/pull/228 .

Good fix and good for sending them a merge request. I still find it kinda baffling glibc would have this behavior for a trailing colon (:). Like, I know it's probably legacy/comparability, but it feels like a security nightmare. ./ should be explicit, not implicit.

Also for leading colons. (but you probably knew that)
Post reply on HN