How Torch broke ls and made me vulnerable • Hacker News Board

Re: How Torch broke ls and made me vulnerable

#11

Post by djsumdog » Fri, Jun 09, 2017, 6:12 AM UTC

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.

Re: How Torch broke ls and made me vulnerable

#12

Post by AceJohnny2 » Fri, Jun 09, 2017, 6:37 AM UTC

More concerning to me is that ld.so will interpret a trailing `:` in LD_LIBRARY_PATH to mean to include PWD.

Where is this documented? It's not indicated in ld.so's manpage:

http://man7.org/linux/man-pages/man8/ld.so.8.html

Sounds like a bug in GNU's ld.so more than anything.

Re: How Torch broke ls and made me vulnerable

#13

Post by ChristianGeek » Fri, Jun 09, 2017, 7:07 AM UTC

lloydde wrote: post #9

Buried in there is "Torch machine learning library", which then allowed me to figure out what software was being blamed. http://torch.ch/

At least you didn't read "ls " as "is" with a capital "i"...I only read it it to un-confuse myself!

Re: How Torch broke ls and made me vulnerable

#14

Post by RubyPinch » Fri, Jun 09, 2017, 7:11 AM UTC

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…

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!)

Re: How Torch broke ls and made me vulnerable

#15

Post by ratmice » Fri, Jun 09, 2017, 7:19 AM UTC

AceJohnny2 wrote: post #12

More concerning to me is that ld.so will interpret a trailing `:` in LD_LIBRARY_PATH to mean to include PWD. Where is this documented? It's not indicated in ld.so's manpage: http://man7.org/linux/man-pages/man8/ld.so.8.html Sounds like a bug in GNU's ld.so more than anything.

It is documented in the elf specification (however I agree it should be documented or preferably excised from ld.so)

http://www.sco.com/developers/gabi/latest/ch5.dynamic.html#s...

The dynamic array tag DT_RUNPATH gives a string that holds a list of directories, separated by colons (:). For example, the string /home/dir/lib:/home/dir2/lib: tells the dynamic linker to search first the directory /home/dir/lib, then /home/dir2/lib, and then the current directory to find dependencies.

The following values would be equivalent to the previous example:

LD_LIBRARY_PATH=/home/dir/usr/lib:/home/dir2/usr/lib:

Re: How Torch broke ls and made me vulnerable

#16

Post by pawadu » Fri, Jun 09, 2017, 7:33 AM UTC

AceJohnny2 wrote: post #12

More concerning to me is that ld.so will interpret a trailing `:` in LD_LIBRARY_PATH to mean to include PWD. Where is this documented? It's not indicated in ld.so's manpage: http://man7.org/linux/man-pages/man8/ld.so.8.html Sounds like a bug in GNU's ld.so more than anything.

Note that this happens anytime you mistype a variable, e.g.

    export FOOBAR=/usr/local/lib
    export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$FOOBAL

So yeah, fix the source of the problem in ld.so, don't blame it on Torch.

Re: How Torch broke ls and made me vulnerable

#17

Post by catdog » Fri, Jun 09, 2017, 9:17 AM UTC

binarycrusader wrote: post #7

Torch probably doesn't even need to set LD_LIBRARY_PATH. If LD_LIBRARY_PATH is only being set so that binaries distributed by torch work, then I'd strongly suggest they use RUNPATH instead with $ORIGIN. There are examples in various places: https://enchildfone.wordpress.com/2010/03/23/a-description-o... http://man7.org/linux/man-pages/man8/ld.so.8.html http://longwei.github.io/rpath_origin/ LD_LIBRARY_PATH is really…

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.

Re: How Torch broke ls and made me vulnerable

#18

Post by parmesan » Fri, Jun 09, 2017, 9:19 AM UTC

foota wrote: post #6

Seems like this may almost have been better done through a disclosure channel with torch?

Indeed, first thing alert the devs and let them sort it out..

Re: How Torch broke ls and made me vulnerable

#19

Post by lloeki » Fri, Jun 09, 2017, 9:52 AM UTC

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…

> 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

Re: How Torch broke ls and made me vulnerable

#20

Post by DarkKomunalec » Fri, Jun 09, 2017, 10:55 AM UTC

AceJohnny2 wrote: post #12

More concerning to me is that ld.so will interpret a trailing `:` in LD_LIBRARY_PATH to mean to include PWD. Where is this documented? It's not indicated in ld.so's manpage: http://man7.org/linux/man-pages/man8/ld.so.8.html Sounds like a bug in GNU's ld.so more than anything.

Even if it was clearly documented, it's still a terrible idea. The OS should try to make it difficult, ideally impossible, to accidentally introduce vulnerabilities.