[Python-Dev] Remove tempfile.mktemp()

[Victor Stinner]

Hi,

I'm not really convinced that mktemp() should be made "more secure".
To be clear: mktemp() is vulnerable by design. It's not a matter of
entropy. You can watch the /tmp directory using inotify and "discover"
immediately the "secret" filename, it doesn't depend on the amount of
entropy used to generate the filename. A function is either unsafe or
secure.

Why mktemp() only uses 8 characters? Well, I guess that humans like to
be able to copy manually (type) a filename :-)

Note: For the ones who didn't notice, "mktemp()" name comes from a
function with the same name in the libc.
http://man7.org/linux/man-pages/man3/mktemp.3.html

Victor

Le mer. 20 mars 2019 à 12:29, Anders Munch <ajm at flonidan.dk> a écrit :
>
> Nathaniel J. Smith:
> > Historically, mktemp variants have caused *tons* of serious security
> > vulnerabilities. It's not a theoretical issue.
>
> All the more reason to have a standard library function that gets it right.
>
> > The choice of ENTROPY_BYTES is an interesting question. 16 (= 128 bits) would
> > be a nice "obviously safe" number, and gives 22-byte filenames. We might be
> > able to get away with fewer, if we had a plausible cost model for the
> > attack. This is another point where a security specialist might be helpful :-).
>
> I'm not a security specialist but I play one on TV.
> Here's my take on it.
>
> Any kind of brute force attack will require at least one syscall per try, to
> create a file or check if a file by a given name exists.  It's a safe assumption
> that names have to be tried individually, because if the attacker has a faster
> way of enumerating existing file names, then the entropy of the filename is
> worthless anyway.
>
> That means even with only 41 bits of entry, the attacker will have make 2^40
> tries on average.  For an individual short-lived file, that could be enough;
> even with a billion syscalls per second, that's over a thousand seconds, leaving
> plenty of time to initiate whatever writes the file.
>
> However, there could be applications where the window of attack is very long,
> hours or days even, or that are constantly writing new temporary files, and
> where the attacker can keep trying at a rapid pace, and then 41 bits is
> definitely not secure.
>
> 128 bits seems like overkill: There's no birthday attack because no-one keeps
> 2^(ENTROPY_BITS/2) files around, and the attack is running on the attackee's
> system, so there's no using specialised accelerator hardware.  I'd say 64 bits
> is enough under those circumstances, but I wouldn't be surprised if a better
> security specialist could make a case for more.  So maybe go with 80 bits,
> that's puts it at 15 or 16 characters.
>
>
> Med venlig hilsen/Best regards
>
>  Anders Munch
> Chief Security Architect
>
> T: +45 76266981  *  M: +45 51856626
> ajm at flonidan.dk  *  www.flonidan.com
>  FLONIDAN A/S  *  Islandsvej 29  *  DK-8700 Horsens  *  CVR: 89919916
> Winner of the 2018 Frost & Sullivan Customer Leadership Award
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/vstinner%40redhat.com



-- 
Night gathers, and now my watch begins. It shall not end until my death.