Date: Sat, 19 Oct 1996 11:50:40 +1000 From: Andrew Tridgell <tridge@arvidsjaur.anu.edu.au> To: bde@zeta.org.au Cc: freebsd-hackers@FreeBSD.org, Guido.vanRooij@nl.cis.philips.com, julian@whistle.com Subject: Re: fix for symlinks in /tmp (fwd) FYI Message-ID: <96Oct19.115050%2B1000est.65052-172%2B234@arvidsjaur.anu.edu.au> In-Reply-To: <199610190115.LAA27084@godzilla.zeta.org.au> (message from Bruce Evans on Sat, 19 Oct 1996 11:15:27 %2B1000)
next in thread | previous in thread | raw e-mail | index | archive | help
> >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? > > Not in FreeBSD. sorry to be so dumb, but do you mean "not in FreeBSD" as in "FreeBSD is not vulnerable" or "not in FreeBSD" as in "gcc on FreeBSD doesn't do the right thing" I strongly suspect that gcc does the same thing on all platforms, so its probably vulnerable on all platforms. > There is still a race (with a much smaller window) if O_EXCL isn't > used even if symlinks aren't followed. hmmm, do you mean the user creating a world writeable file (not a symlink) in /tmp of the right name? Its not as nasty as the things you can do with symlinks, but yes, it can be used to subvert security. Its only a security risk when the program doing the /tmp stuff can be made to do something nasty by changing the data in its /tmp files. Luckily this is much harder than the symlink style of attack (where you just point the link at some other programs data file, thereby giving you a much wider range of programs to attack) I suppose you could do this with gcc by changing the assembler code in the /tmp file to do something nasty, perhaps while root is compiling the kernel. It would not be easy though. Cheers, Andrew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?96Oct19.115050%2B1000est.65052-172%2B234>