[Python-Dev] Some more on the 'tempfile' naming security issue

[Peter Funk]

> [Peter Funk(me)]
> > On <http://www.insecure.org/sploits/gcc.tmpfiles.html> you can find a
> > working example which exploits this vulnerability in older versions
> > of GCC.
> >
> > The basic idea is indeed very simple:  Since the /tmp directory is
> > writable for any user, the bad guy can create a symbolic link in /tmp
> > pointing to some arbitrary file (e.g. to /etc/passwd).  The attacked
> > program will than overwrite this arbitrary file (where the programmer
> > really wanted to write something to his tempfile instead).  Since this
> > will happen with the access permissions of the process running this
> > program, this opens a bunch of vulnerabilities in many programs
> > writing something into temporary files with predictable file names.
 
[Tim Peters]:
> I can understand all that, but does it have anything to do with Python's
> tempfile module?  gcc wasn't fixed by changing glibc, right?  

Okay.  But people seem to have the opponion, that "application programmers"
are dumb and "system programmers" are clever and smart. ;-)  So they seem
to think, that the library should solve possible security issues.
I don't share this oppinion, but if a some problem can be solved once
and for all in a library, this is better than having to solve this over and
over again in each application.

Concerning 'tempfile' this would either involve changing (or extending) 
the interface (IMO a better approach to this class of problems) or if the
goal is to solve this for existing applications already using 'tempfile', to 
play games with the filenames returned from 'mktemp()'.  This would require
to make them to be truely random... which AFAIK can't be achieved with 
traditional coding techniques and would require access to a secure white
noise generator.  But may be I'm wrong.

> Playing games
> with the file *names* doesn't appear to me to solve anything; the few posts
> I bumped into where that was somehow viewed as a Good Thing were about
> Solaris systems, where Sun kept the source for generating the "new,
> improved, messy" names secret.  In Python, any attacker can read the code
> for anything we do, which it makes it much clearer that a name-game approach
> is half-assed.

I agree.  But I think we should at least extend the documentation
of 'tempfile' (Fred?) to guide people not to write Pythoncode like
	mytemp = open(tempfile.mktemp(), "w")
in programs that are intended to be used on Unix systems by arbitrary
users (possibly 'root').  Even better:  Someone with enough spare time 
should add a new function 'mktempfile()', which creates a temporary 
file and takes care of the security issue and than returns the file 
handle.  This implementation must take care of race conditions using
'os.open' with the following flags:

       O_CREAT If the file does not exist it will be created.
       O_EXCL  When used with O_CREAT, if the file already  exist
	       it is  an error and the open will fail. 

> and-people-whine-about-worming-around-bad-decisions-in-
>     windows<wink>-ly y'rs  - tim

I don't whine.  But currently I've more problems with my GUI app using
Tkinter&Pmw on the Mac <wink>.

Regards, Peter
-- 
Peter Funk, Oldenburger Str.86, 27777 Ganderkesee, Tel: 04222 9502 70, Fax: -60
Wer sich zu wichtig für kleine Arbeiten hält,
ist meist zu klein für wichtige Arbeiten.     --      Jacques Tati