Re: mktemp() and friends

[deraadt () cvs openbsd org (Theo de Raadt)]

> In some mail from Theo de Raadt, sie said:
> [...]
> > Has anyone done a major cleanup of /tmp holes (ie. mktemp and friends)?
>
> Personally, I think they should all return either "FILE *" or an open
> file descriptor so even if /tmp isn't +t, you already have opened the
> file you actually asked for.  But that's just IMHO.

Uhm, +t doesn't actually help much for the race at file creation time.
You are still symbolic link raceable since mktemp filenames are
guessable.  The filenames are guessable since the 6 X's are written
over by not much more than just the pid -- mktemp() wants to generate
low-collision-rate filenames.

(Wham! The user's .rhosts gets 5000s line of cpp output written into it!)

Sigh.  I think the answer to my question is likely "No" -- once again,
noone (besides OpenBSD) is proactively fixing things; they just
respond when they see an exploit.  In 99% of occurances in the src
tree it is enough to replace mktemp() uses with mkstemp().  There's a
few other tricky spots (shell scripts).  OpenBSD has done these fixes
-- it took myself and 3 other guys about a week but it sure is nice to
know a yet another class of holes is basically extinct.  We fixed all
those we found, even the one in patch(1)... not only the ones in setuid
programs. (The gcc one remains to be fixed, it's a difficult one.)

In my opinion it doesn't need to be a root hole to be a security hole.
Take a look at the interesting consequences of a buffer overflow in
/usr/games/* if the "dm" is setuid games...  but even if I didn't have
a setuid program of any kind laying around, on a busy system if the
other users' actions could be predicted they could have their filespace
whacked by a wide variety of /tmp races.

(Psst. Who runs fortune in their .login?)


---
This space not left unintentionally unblank.            deraadt () theos com
www.OpenBSD.org -- We're fixing security problems so you can sleep at night.