Two glibc vulnerabilities
Posted Oct 29, 2010 14:50 UTC (Fri) by
jzbiciak (
✭ supporter ✭, #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)