Re: tmpnam vs mkstemp, was Re: [Exim] Problem with compiling…

Inizio della pagina
Delete this message
Reply to this message
Autore: Exim Users Mailing List
Data:  
To: exim-users
Oggetto: Re: tmpnam vs mkstemp, was Re: [Exim] Problem with compiling exim-3.22 on Linux
[ On Friday, March 30, 2001 at 21:27:56 (+0100), Ian Jackson wrote: ]
> Subject: Re: tmpnam vs mkstemp, was Re: [Exim] Problem with compiling exim-3.22 on Linux
>
> This is completely absurd, of course. An implementation of tmpfile()
> which does *not* create the file in the right way cannot safely be
> used by *any* program.


Well, that's not *exactly* true. There have been many broken
implementations that were used "safely" for decades by many programs.
The problem is that such programs are rarely, if ever, used in
situations where they themselves will exploit the race conditions in
these broken implementations.

> Therefore the spec of tmpfile() must include that requirement, whether
> or not it's stated in POSIX or anywhere else.


Specs don't matter a hoot when there are dozens of variants of the
broken implementation(s) out there *now* in production machines.

Certainly the implication is there in even the original tmpfile()
documentation that it should be secure, but unfortunately it's very much
too easy to write a broken implementation that conforms to the
documentation. People are very bad in general at writing code that's
safe from such race conditions, especially if they don't learn to think
from the point of view of the attacker (eg. how can I manipulate the
environment in which this function executes in order to make it do
something unexepected?).

> Furthermore, tmpfile()
> is widely used, so if it is broken on your system then nearly
> everything on the system will be broken and you have no hope of
> security.


Yup. In an absolute sense that's absolutely true. That's very much the
state of many (most?) commercial systems today, and not just because of
tmpfile().

> Phil: if you're worried about being blamed for crap libcs, make an
> autoconf test that spots if tmpfile is broken and makes the build fail
> if it is. I'll have a go at writing you one if you like.


The test isn't so trivial for some variations of brokenness.

> [1] If your OS vendor won't and you don't have the source code, get a
> better OS vendor.


If everyone did that then nobody would run IRIX, or Solaris, or HP/UX,
for example. :-)

What bugs me is when the compiler (well, the linker) on NetBSD warns
about suspect use of the wrong function even when the core library
routine is supposed to be fixed! ;-)

-- 
                            Greg A. Woods


+1 416 218-0098      VE3TCP      <gwoods@???>      <robohack!woods>
Planix, Inc. <woods@???>; Secrets of the Weird <woods@???>