From owner-freebsd-hackers Fri Oct 18 17:42:17 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id RAA05114 for hackers-outgoing; Fri, 18 Oct 1996 17:42:17 -0700 (PDT) Received: from arvidsjaur (arvidsjaur.anu.edu.au [150.203.160.29]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id RAA05108 for ; Fri, 18 Oct 1996 17:42:15 -0700 (PDT) Received: by arvidsjaur.anu.edu.au id <65033-172>; Sat, 19 Oct 1996 10:40:34 +1000 From: Andrew Tridgell To: bde@zeta.org.au CC: Guido.vanRooij@nl.cis.philips.com, julian@whistle.com, freebsd-hackers@FreeBSD.org In-reply-to: <199610182334.JAA24319@godzilla.zeta.org.au> (message from Bruce Evans on Sat, 19 Oct 1996 09:34:55 +1000) Subject: Re: fix for symlinks in /tmp (fwd) FYI Reply-to: Andrew.Tridgell@anu.edu.au Message-Id: <96Oct19.104034+1000est.65033-172+226@arvidsjaur.anu.edu.au> Date: Sat, 19 Oct 1996 10:40:21 +1000 Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > 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.