OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Bugtraq archives for 1st quarter (Jan-Mar) 1998: Re: another /tmp race: `perl -e' opens temp file not safely

Re: another /tmp race: `perl -e' opens temp file not safely

stanislav shalunov (shalunovMCCME.RU)
Sun, 8 Mar 1998 03:53:09 GMT 

>>>>> "deraadt" == Theo de Raadt <deraadtcvs.openbsd.org> writes:

 deraadt> Moreover, Stanislav's patch retained the use of of mktemp(),
 deraadt> which means his fixed perl can still be denial-of-serviced

This is true.  You can still DOS Perl after my quick patch (if you win
the race).  I am afraid that the same might apply to your patch as
well, at least on some systems and to some degree.  But surely
mkstemp() is a better thing to do.

 deraadt> The correct fix is to use mkstemp(), which is designed to be
 deraadt> (much more) impervious to these kinds of races.

It is.  However, on many systems it only tries a finite number of
times; if you guess the name every time it open()s you've denied
service to the calling program.  It is much harder to do (you need to
win a lot of races) but theoretically it's possible.  So the program
still isn't correct in the strict sense.  (This does not apply to
OpenBSD: its _gettemp() will try forever which is the right thing to
do because attacker cannot win an infinite number of races--or to put
it more accurately, has probability zero of winning $\aleph_0$ races.)

All this complexity of trivial things (just open a temp file) is one
of the reasons I think the whole idea of /tmp is a fundamental
misdesign and eventually one should be able to chmod it to 755 (while
programs should use per-user TMPDIRs).