Bug 1039915 (CVE-2013-7040) - CVE-2013-7040 python: hash secret can be recovered remotely
Summary: CVE-2013-7040 python: hash secret can be recovered remotely
Alias: CVE-2013-7040
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On: 1039917 1039918 1039919
Blocks: 1039920
TreeView+ depends on / blocked
Reported: 2013-12-10 10:13 UTC by Ratul Gupta
Modified: 2021-02-17 07:05 UTC (History)
19 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-12-18 07:03:49 UTC

Attachments (Terms of Use)

Description Ratul Gupta 2013-12-10 10:13:13 UTC
This is a followup to CVE-2012-1150 (hash table collision CPU usage DOS in CPython).

http://bugs.python.org/issue14621 points out that the hash secret in CPython can be recovered remotely, so while the original fix addressed the "blind DOS" problem (of being able to DOS any Python based service with a single prepared payload), it didn't completely eliminate the potential for remote DOS attacks based on hash collisions. (http://bugs.python.org/issue14621#msg173455 has the details)

Python 3.4+ will use SipHash by default (http://www.python.org/dev/peps/pep-0456), which should resolve the vulnerability completely.


Comment 1 Ratul Gupta 2013-12-10 10:16:19 UTC
Created python tracking bugs for this issue:

Affects: fedora-all [bug 1039917]

Comment 2 Ratul Gupta 2013-12-10 10:16:24 UTC
Created python26 tracking bugs for this issue:

Affects: epel-5 [bug 1039919]

Comment 3 Ratul Gupta 2013-12-10 10:16:28 UTC
Created python3 tracking bugs for this issue:

Affects: fedora-all [bug 1039918]

Comment 4 Huzaifa S. Sidhpurwala 2013-12-18 04:03:21 UTC
This issue is an offshoot of CVE-2012-1150. This flaw which essentially causes hash collisions and hence denial of service, was fixed by introducing a random salt value which could be read from /dev/urandom or provided by user on invocation of the python interpreter using an environment variable.

However it was found that whether the keys (in the hash table) collided or not would only depend on the last 8 bits of the random value. This issue could be exploited by generating multiple datasets, which could test all the possible 256 combinations of the random hash. Then the attacker could evaluate the time taken by each request to be processed and based on the one which takes maximum time, he could obtain the last 8 bits of the secret seed value used for randomization.

This maximum impact of this flaw is denial of service, depending on how the python application is written to handle remote requests.

Python upstream examined various non-cryptographic hash algorithms and their implementations, but it seemed that most of them were vulnerable to some form of hash collisions and therefore would not serve their purpose in the long term.

In the end it was found that SipHash was most suitable for this purpose. SipHash is a cryptographic pseudo random function with a 128-bit seed and 64-bit output. It is designed to be a fast and secure keyed hash algorithm. 

Upstream has proposed a Python Enhancement Proposal document PEP 456 with the required details:


Upstream does not intend to back port this patch to python-2.x, and is currently only applied to python-3.4. The patch is intrusive.

Comment 5 Huzaifa S. Sidhpurwala 2013-12-18 07:03:49 UTC
Python applications should validate the length/size of the data before storing the data in hash tables or dictionaries this should stop most of the hash-collision related denial of service attacks.


This issue affects the version of python as shipped with Red Hat Enterprise Linux 5 and 6. There are currently no plans to fix this issue. For more details please refer to  https://bugzilla.redhat.com/show_bug.cgi?id=1039915#c4

Note You need to log in before you can comment on or make changes to this bug.