[Python-Dev] Is the tempfile module really a security risk?

[Guido van Rossum]

Every few months I receive patches that purport to make the tempfile
module more secure.  I've never felt that it is a problem.  What is
with these people?  My feeling about these suggestions has always been
that they have read about similar insecurities in C code run by the
super-user, and are trying to get the teacher's attention by proposing
something clever.

Or is there really a problem?  Is anyone in this forum aware of
security issues with tempfile?  Should I worry?  Is the
"random-tempfile" patch that the poster below suggested worth
applying?

--Guido van Rossum (home page: http://www.python.org/~guido/)

------- Forwarded Message

Date:    Sun, 21 May 2000 19:34:43 +0200
From:    =?iso-8859-1?Q?Ragnar_Kj=F8rstad?= <ragnark@vestdata.no>
To:      Guido van Rossum <guido@python.org>
cc:      patches@python.org
Subject: Re: [Patches] Patch to make tempfile return random filenames

On Sun, May 21, 2000 at 12:17:08PM -0700, Guido van Rossum wrote:
> Hm, I don't like this very much.  Random sequences have a small but
> nonzero probability of generating the same number in rapid succession
> -- probably one in a million or so.  It would be very bad if one in a
> million rums of a particular application crashed for this reason.
> 
> A better way do prevent this kind of attack (if you care about it) is
> to use mktemp.TemporaryFile(), which avoids this vulnerability in a
> different way.
> 
> (Also note the test for os.path.exists() so that an attacker would
> have to use very precise timing to make this work.)

1. the path.exist part does not solve the problem. It causes a racing
condition that is not very hard to get around, by having a program
creating and deleting the file at maximum speed. It will have a 50%
chance of breaking your program.

2. O_EXCL does not always work. E.g. it does not work over NFS - there
are probably other broken implementations too.

3. Even if mktemp.TemporaryFile had been sufficient, providing mktemp in
this dangerous way is not good. Many are likely to use it either not
thinking about the problem at all, or assuming it's solved in the
module.

4. The problems you describe can easily be overcome. I removed the
counter and the file-exist check because I figgured they were no longer
needed. I was wrong. Either a larger number should be used and/or
counter and or file-exist check. Personally I would want the random part
to bee large enough not have to worry about collisions either by chance,
after a fork, or by deliberate attack.


Do you want a new patch that adresses theese problems better?


- -- 
Ragnar Kjørstad

_______________________________________________
Patches mailing list
Patches@python.org
http://www.python.org/mailman/listinfo/patches

------- End of Forwarded Message