User: Password:
|
|
Subscribe / Log in / New account

Two glibc vulnerabilities

Two glibc vulnerabilities

Posted Oct 29, 2010 14:50 UTC (Fri) by jzbiciak (subscriber, #5246)
Parent article: Two glibc vulnerabilities

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?


(Log in to post comments)


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds