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>