insecure os.urandom on VMS

[zooko]

BPO	9123
Nosy	@loewis, @vstinner

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2012-05-02.06:31:08.444>
created_at = <Date 2010-06-30.03:48:33.727>
labels = ['type-security', 'library']
title = 'insecure os.urandom on VMS'
updated_at = <Date 2012-05-02.06:31:08.443>
user = 'https://bugs.python.org/zooko'

bugs.python.org fields:

activity = <Date 2012-05-02.06:31:08.443>
actor = 'loewis'
assignee = 'none'
closed = True
closed_date = <Date 2012-05-02.06:31:08.444>
closer = 'loewis'
components = ['Library (Lib)']
creation = <Date 2010-06-30.03:48:33.727>
creator = 'zooko'
dependencies = []
files = []
hgrepos = []
issue_num = 9123
keywords = []
message_count = 6.0
messages = ['108963', '108964', '108965', '158203', '158204', '159777']
nosy_count = 4.0
nosy_names = ['loewis', 'zooko', 'vstinner', 'adiroiban']
pr_nums = []
priority = 'normal'
resolution = 'wont fix'
stage = 'patch review'
status = 'closed'
superseder = None
type = 'security'
url = 'https://bugs.python.org/issue9123'
versions = ['Python 2.6', 'Python 3.1', 'Python 2.7', 'Python 3.2', 'Python 3.3']

[zooko]

os.urandom() on VMS invokes OpenSSL's RAND_pseudo_bytes(). That is documented on:

http://www.openssl.org/docs/crypto/RAND_bytes.html

as being predictable and therefore unsuitable for many cryptographic purposes. This is inconsistent with the documentation of os.urandom():

"""
urandom(n) -> str\n\n\
Return a string of n random bytes suitable for cryptographic use.
"""

This probably means that users of Python on VMS are vulnerable to attack based on the predictability of the results they get from os.urandom().

Honestly, I would have guessed that there *were* no users of Python on VMS when I started this bug report, but look--apparently there are:

http://www.vmspython.org

To fix this, change the call from RAND_pseudo_bytes() to RAND_bytes(). It has the same type signature and actually does what os.urandom() needs.

[zooko]

HACK Zooko-Ofsimplegeos-MacBook-Pro:~/playground/python/release27-trunk$ svn diff
Index: Modules/posixmodule.c
===================================================================

--- Modules/posixmodule.c       (revision 82382)
+++ Modules/posixmodule.c       (working copy)
@@ -8481,7 +8481,7 @@
     result = PyString_FromStringAndSize(NULL, howMany);
     if (result != NULL) {
         /* Get random data */
-        if (RAND_pseudo_bytes((unsigned char*)
+        if (RAND_bytes((unsigned char*)
                               PyString_AS_STRING(result),
                               howMany) < 0) {
             Py_DECREF(result);

[zooko]

This issue is a security vulnerability.

[vstinner]

This issue is a security vulnerability.

I disagree, it's just an issue of a comment in the C code. The Python documentation doesn't guarantee that os.urandom() is cryptographic.

Use ssl.RAND_bytes(), added to Python 3.3, if you need cryptographic random numbers.

By the way, VMS is no more supported in Python 3.3, see the PEP-11:

Name:             VMS
Unsupported in:   Python 3.3
Code removed in:  Python 3.4

[vstinner]

•    if (RAND_pseudo_bytes((unsigned char*)
  

+ if (RAND_bytes((unsigned char*)

This is not a good idea: RAND_bytes() is blocking, whereas os.urandom() doesn't block on other platforms. os.urandom() is similar to /dev/urandom (non blocking), whereas /dev/random is blocking. With this patch, Python may block at startup if there is not enough entropy.

[loewis]

I'm closing this as "won't fix". Unless somebody is able to report that they actually tested the proposed change successfully, there is no point in adding it. Most likely, Python won't even build on VMS, in which case this is not a security issue at all.