If the directory that contains the executable can be replaced with an exploit library object between the time $ORIGIN is expanded and when the value is used, the library will be loaded and the attacker can do what they like. It is essentially a race condition, but one that can be reliably won by the attacker. Ormandy's example basically pauses the execution of a ping that has been hardlinked into an attacker-controlled directory after the expansion of $ORIGIN has been done. He then removes the directory and its contents, and puts a library that has exploit code in its initialization function in the place of the directory.
Ok, maybe my coffee hasn't kicked in yet. Why is it necessary to remove / replace the attacker-controlled directory in this case?
For example, suppose /var/tmp and /bin are (perhaps unwisely) on the same partition:
$ mkdir /var/tmp/evil $ ln /bin/ping /var/tmp/evil/ping $ cp $HOME/libevil.so /var/tmp/evil/. $ export LD_AUDIT='$ORIGIN/libevil.so' $ /var/tmp/evil/ping # whoami root
Or is it that the linker only expands LD_AUDIT if it is precisely '$ORIGIN', and so you have to replace the directory itself with a library file?
Also, am I correct in thinking that if you keep your untrusted-user-writeable directories on different partitions from your setuid executables, you'll thwart this attack?
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds