Date: Sat, 19 Oct 1996 10:40:21 +1000 From: Andrew Tridgell <tridge@arvidsjaur.anu.edu.au> To: bde@zeta.org.au Cc: Guido.vanRooij@nl.cis.philips.com, julian@whistle.com, freebsd-hackers@FreeBSD.org Subject: Re: fix for symlinks in /tmp (fwd) FYI Message-ID: <96Oct19.104034%2B1000est.65033-172%2B226@arvidsjaur.anu.edu.au> In-Reply-To: <199610182334.JAA24319@godzilla.zeta.org.au> (message from Bruce Evans on Sat, 19 Oct 1996 09:34:55 %2B1000)
next in thread | previous in thread | raw e-mail | index | archive | help
> Symlinks have the same ownership as their parent directory in BSD4.4, so
> this patch would be almost equivalent to disallowing symlinks in sticky
> directories. E.g., /tmp is owned by bin, and no process should have
> uid bin, so symlinks in /tmp would never be followed (even for root :-).
ahhh, ok. Then my suggested change is useless for BSD4.4.
Maybe you can come up with a different fix?
It would be nice if this (or a equivalent fix) made it into all the
major Unixes. I'm really sick of these "symlink-in-/tmp" bugs. There
have been just too many of them.
> Our mkstemp() and mktemp() use O_EXCL, and gcc seems to use mktemp(),
> so I think gcc isn't vulnerable.
Really? mktemp() actually creates the file? I thought that was what
tmpfile() was for.
Hmmm, I'll go look at my NetBSD system ....
yep, nm on libc.a shows:
00000028 T _mktemp
U _open
U _stat
so it looks like it might possibly be creating the file (and
safely?). Now to test with a program ....
main()
{
char template[100] = "/tmp/foo.XXXXXX";
puts(mktemp(template));
}
running this does not create the file in /tmp. Heres the relevant
ktrace output:
2774 a.out CALL stat(0xf7fff930,0xf7fff800)
2774 a.out NAMI "/tmp"
2774 a.out RET stat 0
2774 a.out CALL stat(0xf7fff930,0xf7fff800)
2774 a.out NAMI "/tmp/foo.002774"
2774 a.out RET stat -1 errno 2 No such file or directory
and thats all that has anything to do with /tmp.
So how does this protect you from /tmp symlink attacks?
I wonder why mktemp() references open in the C library? I wonder if I
have any BSD libc sources handy ....
ahhh, ok, mktemp() calls:
_gettemp(char *path,int *doopen)
and the doopen parameter controls if the open is used to create it
with O_EXCL set. mktemp() looks like this:
char *
mktemp(path)
char *path;
{
return(_gettemp(path, (int *)NULL) ? path : (char *)NULL);
}
so doopen is set to NULL, meaning don't create. This means anyone
using mktemp() still needs to be careful about setting O_EXCL. Does
gcc on BSD do this?
anyway, we are getting a bit off track. My suggested fix for Linux
fixes the problem even for bad programmers. Its just a pity that the
symlink implementation in BSD4.4 (nice though it is) makes this fix
unworkable.
Cheers, Andrew
PS: My BSD system is a bit old (its NetBSD-current from near the end
of last year) so things may have changed. We were evaluating NetBSD vs
Linux for the AP1000+ at that time.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?96Oct19.104034%2B1000est.65033-172%2B226>