Movatterモバイル変換
[0]ホーム
[Python-Dev] Remove tempfile.mktemp()
Victor Stinnervstinner at redhat.com
Wed Mar 20 07:45:40 EDT 2019
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 ofentropy. You can watch the /tmp directory using inotify and "discover"immediately the "secret" filename, it doesn't depend on the amount ofentropy used to generate the filename. A function is either unsafe orsecure.Why mktemp() only uses 8 characters? Well, I guess that humans like tobe able to copy manually (type) a filename :-)Note: For the ones who didn't notice, "mktemp()" name comes from afunction with the same name in the libc.http://man7.org/linux/man-pages/man3/mktemp.3.htmlVictorLe 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.
More information about the Python-Devmailing list
[8]ページ先頭