3 ms·

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

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 http://man7.org/linux/man-pages/man8/ld.so.8.html Sounds like a bug in GNU's ld.so more than anything.

ratmice 9y ago
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#shobj_dependencies 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:
pawadu 9y ago
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.
DarkKomunalec 9y ago
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.
zwp 9y ago
> Sounds like a bug in GNU's ld.so more than anything. It's neither unique to glibc (AIX, Solaris) nor to LD_LIBRARY_PATH (PATH), nor trailing colons (leading colons, adjacent colons). This de facto standard becomes a little more obvious when one considers a likely implementation (iterating over "strchr(arg, ':')" or whatever). Any of these sequences then will give up an empty string: PATH=:/foo PATH=/foo: PATH=/foo::/bar And an empty string is equivalent to dot for chdir(2). zwp:/tmp$ cd '' zwp:/tmp$ pwd /tmp zwp:/tmp$ (This is not the same as plain "cd" (ie with no args), which is a special case that takes you $HOME, of course). I agree it's surprising and potentially dangerous. FWIW, the execp() functions hide a similar wtf. From the Linux man page: The file is sought in the colon-separated list of directory pathnames specified in the PATH envi‐ ronment variable. If this variable isn't defined, the path list defaults to the current directory followed by the list of directories returned by confstr(_CS_PATH). Security conscious programs that clear the environment and then call eg execlp() end up searching dot before the system path. Yay.

ratmice 9y ago

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#shobj_dependencies 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:

pawadu 9y ago

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.

DarkKomunalec 9y ago

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.

zwp 9y ago

> Sounds like a bug in GNU's ld.so more than anything. It's neither unique to glibc (AIX, Solaris) nor to LD_LIBRARY_PATH (PATH), nor trailing colons (leading colons, adjacent colons). This de facto standard becomes a little more obvious when one considers a likely implementation (iterating over "strchr(arg, ':')" or whatever). Any of these sequences then will give up an empty string: PATH=:/foo PATH=/foo: PATH=/foo::/bar And an empty string is equivalent to dot for chdir(2). zwp:/tmp$ cd '' zwp:/tmp$ pwd /tmp zwp:/tmp$ (This is not the same as plain "cd" (ie with no args), which is a special case that takes you $HOME, of course). I agree it's surprising and potentially dangerous. FWIW, the execp() functions hide a similar wtf. From the Linux man page: The file is sought in the colon-separated list of directory pathnames specified in the PATH envi‐ ronment variable. If this variable isn't defined, the path list defaults to the current directory followed by the list of directories returned by confstr(_CS_PATH). Security conscious programs that clear the environment and then call eg execlp() end up searching dot before the system path. Yay.