classification
Title: uuid module falls back to unsuitable RNG
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 3.9, Python 3.8, Python 3.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: rhettinger Nosy List: Arfrever, christian.heimes, loewis, ncoghlan, pitrou, rhettinger, vstinner
Priority: normal Keywords: patch

Created on 2012-06-27 14:01 by christian.heimes, last changed 2019-08-28 22:19 by vstinner. This issue is now closed.

Files
File name Uploaded Description Edit
issue15206.patch christian.heimes, 2012-06-27 21:11 review
Messages (19)
msg164157 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2012-06-27 14:01
The uuid module uses Mersenne Twister from the random module as last fallback. However a MT isn't suitable for cryptographic purposes. The module should first try to use os.urandom() and then perhaps use its own instance of random.Random, similar to uuid_generate_* [1]

The problem doesn't apply to most modern platforms as the uuid module uses either libuuid or the Windows API with ctypes. Therefore I consider the real world severity as low. It may not require a backport to Python 2.x.

[1] http://linux.die.net/man/3/uuid_generate
msg164181 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2012-06-27 18:10
Further analysis:

* uuid1() uses random.randrange() if the system doesn't provide uuid_generate_time

* uuid1() also falls back to random.randrange() in getnode()'s _random_getnode() if no hardware address can be acquired.

* uuid4() is fine as it only falls back to random.randrange() when os.urandom() fails.
msg164185 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2012-06-27 18:29
Can you elaborate why it is unsuitable? None of the uuid functions claim any cryptographic properties, so even if MT was unsuitable for cryptographic purposes, this wouldn't rule it out for generating uuids.
msg164203 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2012-06-27 21:11
IMHO it's all about managing expectations. As libuuid is using a crypto RNG before it falls back to a less suitable RNG. We should follow this example. I couldn't find any information about the implementation details of Window's UuidCreate().

I agree that we can disagree on my reasoning. However the usage of random.random() and random.randint() in uuid is flawed for a second reason. The default instance random._inst doesn't compensate for fork(). After fork() the two processes share the same random state and thus will create the same uuids. For example tempfile._RandomNameSequence re-creates the RNG when it notices a different PID.
msg164207 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2012-06-27 22:22
Are uuid's promised to be cryptographically secure?
msg164210 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2012-06-27 22:44
Not, not by definition. However an uuid generator shall geenerate uuid in a way that make collisions highly improbable. IMHO this verdict implies that an uuid generator should use the cryptographic RNG if available.

The behavior after fork() is clearly a bug as it will generate lots of collisions on systems that fall back to random.
msg164211 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2012-06-27 23:25
> However a MT isn't suitable for cryptographic purposes.
> The module should first try to use os.urandom() and
> then perhaps use its own instance of random.Random,
> similar to uuid_generate_* [1]

os.urandom() is not suitable for cryptographic purposes :-) Python 3.3 has also ssl.RAND_bytes() which is better than os.urandom(), but it's not possible (easy?) to build a custom random.Random class with an arbitrary RNG (like os.urandom or ssl.RAND_bytes).

It would be nice to provide an API to choose the best RNG depending on a set of requirements. I wrote the Hasard library which implements such idea: the library provides "profiles" and chooses the best RNG for a profile. Profiles:
- fast
- secure nonblocking
- secure blocking
- hardware

See the doc directory the Hasard project for details:
https://bitbucket.org/haypo/hasard/
https://bitbucket.org/haypo/hasard/src/82d13450c552/doc/profile_list.rst

See also the issue #12858 for another user of a better RNG.

I'm quite sure that all these RNG issues are a good candidate for a PEP because RNG is complex problem, there are different use cases, various implements, and a lot of common issue (in RNG implementations). Handling fork or not is an important question, which impact performances, for example.

See also the issue #12754: "Add alternative random number generators".
msg164212 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-06-27 23:29
From the /dev/urandom Linux man page:

       If  you  are  unsure  about  whether  you  should  use  /dev/random  or
       /dev/urandom, then probably you want to use the latter.  As  a  general
       rule,  /dev/urandom  should  be  used  for everything except long-lived
       GPG/SSL/SSH keys.

       If a seed file is saved across reboots as recommended below (all  major
       Linux  distributions have done this since 2000 at least), the output is
       cryptographically secure against attackers without local root access as
       soon as it is reloaded in the boot sequence, and perfectly adequate for
       network encryption session keys. 


So, yes, /dev/urandom is suitable for most cryptographic purposes (except long-lived private keys).
msg164213 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2012-06-27 23:38
Antoine beat me to it and he is totally right.

Please don't derail this bug report. I agree with your analysis that the RNG core of random.Random subclass can't be replaced easily and that more implementations for different purposes would be great. You should stick the analysis into a different ticket or write a PEP. This ticket is the wrong place. I'll support you if you keep the ticket on course. ;)

Let's concentrate on the topic at hand and discuss if 

a) my patch handles the fork() issue correctly
b) if it's a good idea to try SystemRandom first
c) a backport to 2.6, 2.7, 3.1 and 3.2 is required
and perhaps
d) if I should open another ticket to work on a general solution for the RNG + fork() issue.
msg164221 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2012-06-28 05:54
> a) my patch handles the fork() issue correctly

If the system has urandom, yes.

> b) if it's a good idea to try SystemRandom first

Certainly.

> c) a backport to 2.6, 2.7, 3.1 and 3.2 is required
> and perhaps

Cannot backport to 2.6 and 3.1; it's not a security issue.

> d) if I should open another ticket to work on a general solution for  
> the RNG + fork() issue.

I'm not quite sure what a solution could be, or wether there is
an issue in the first place, so -0.
msg164230 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2012-06-28 09:05
Am 28.06.2012 07:54, schrieb Martin v. Löwis:
> 
> Martin v. Löwis <martin@v.loewis.de> added the comment:
> 
>> a) my patch handles the fork() issue correctly
> 
> If the system has urandom, yes.

That's the easy and trivial case. It also handles fork() by storing the
PID and comparing it to os.getpid() whenever the RNG is acquired.
msg164231 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-06-28 09:27
+    except Exception:

I don't think that's a good idea. You should list the specific exceptions here (NotImplementedError, OSError perhaps?).
msg164484 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2012-07-01 15:42
The rest of the module uses bar excepts. I could change the signature if you insist.
msg164492 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-07-01 18:40
> The rest of the module uses bar excepts.

It was probably written in prehistoric times :)
The other excepts can be converted later, if the module gets other changes. I don't think it is a deliberate style choice (it would be particularly distasteful :-)).
msg274751 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2016-09-07 04:21
Given the introduction of the secrets module in 3.6, perhaps uuid could be updated to fall back to that rather than to the random module and leave older versions unmodified?
msg274766 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2016-09-07 06:03
> Given the introduction of the secrets module in 3.6, perhaps uuid could be updated to fall back to that rather than to the random module and leave older versions unmodified?

issue15206.patch catchs exceptions on random.SystemRandom error, but the secrets module also uses random.SystemRandom. I don't think that "fallback on secrets" makes sense here, or do I miss something?
msg277356 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2016-09-25 10:30
Past me was a bit too eager...

Only UUID4 are suppose to be random and unpredictable. uuid.UUID4 uses os.urandom() to as RNG. UUID1, UUID3 and UUID5 are more concerned with reducing collisions.
msg350685 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2019-08-28 18:23
The random number generator now reseeds after a fork.

Can this now be closed as "out-of-date" or is there still something that needs to be done?
msg350692 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2019-08-28 22:19
I close the issue. Python 3.7 and newer are fixed. Python 2.7 is still affected, but I consider that it's ok to leave the bug unfixed in this version.

--

> The random number generator now reseeds after a fork.

I confirm that it's done since Python 3.7, and Python 3.6 doesn't accept bugfixes anymore (only security fixes). So the issue is fixed in Python 3.7, 3.8 and master. For the record, the fix was this change:

commit 346cbd351ee0dd3ab9cb9f0e4cb625556707877e
Author: Antoine Pitrou <pitrou@free.fr>
Date:   Sat May 27 17:50:54 2017 +0200

    bpo-16500: Allow registering at-fork handlers (#1715)

Backporting this change to Python 3.6 and 3.5 would be too intrusive and risky. I don't think that this bug is important enough to be qualified as security vulnerability (the issue type is not "Security").


For Python 2.7, honestly, I don't think that the issue matters enough to justify to fix it today, knowning that Python 2.7 will reach its end of life at the end of the year. Moreover, apart Christian Heimes, no user ever complained about this issue.


Note: uuid.uuid4() always used os.urandom(16) which is not affected by this issue on fork. Only uuid.uuid1() and uuid.getnode() has the bug in Python 2.7.
History
Date User Action Args
2019-08-28 22:19:43vstinnersetstatus: open -> closed
versions: + Python 3.7, Python 3.8, Python 3.9, - Python 2.7, Python 3.6
messages: + msg350692

resolution: fixed
stage: resolved
2019-08-28 18:23:20rhettingersetstatus: pending -> open

messages: + msg350685
2016-09-25 10:30:07christian.heimessetstatus: open -> pending
type: security -> behavior
messages: + msg277356
2016-09-07 06:03:31vstinnersetmessages: + msg274766
2016-09-07 04:21:18ncoghlansetnosy: + ncoghlan

messages: + msg274751
versions: + Python 3.6, - Python 3.2, Python 3.3
2012-07-01 18:40:55pitrousetmessages: + msg164492
2012-07-01 15:42:35christian.heimessetmessages: + msg164484
2012-06-28 09:27:29pitrousetmessages: + msg164231
2012-06-28 09:05:06christian.heimessetmessages: + msg164230
2012-06-28 05:55:35loewissetversions: - Python 2.6, Python 3.1
2012-06-28 05:54:51loewissetmessages: + msg164221
2012-06-27 23:38:28christian.heimessetmessages: + msg164213
2012-06-27 23:29:29pitrousetnosy: + pitrou
messages: + msg164212
2012-06-27 23:25:38vstinnersetnosy: + vstinner
messages: + msg164211
2012-06-27 22:44:18christian.heimessetmessages: + msg164210
2012-06-27 22:22:11rhettingersetassignee: rhettinger

messages: + msg164207
nosy: + rhettinger
2012-06-27 21:11:26christian.heimessetfiles: + issue15206.patch
keywords: + patch
messages: + msg164203
2012-06-27 18:29:03loewissetnosy: + loewis
messages: + msg164185
2012-06-27 18:10:54christian.heimessetmessages: + msg164181
2012-06-27 15:56:03Arfreversetnosy: + Arfrever
2012-06-27 14:01:39christian.heimescreate