Bug 1039915 - (CVE-2013-7040) CVE-2013-7040 python: hash secret can be recovered remotely
CVE-2013-7040 python: hash secret can be recovered remotely
Status: CLOSED WONTFIX
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
impact=moderate,public=20131209,repor...
: Security
Depends On: 1039917 1039918 1039919
Blocks: 1039920
  Show dependency treegraph
 
Reported: 2013-12-10 05:13 EST by Ratul Gupta
Modified: 2016-08-23 02:39 EDT (History)
19 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-12-18 02:03:49 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ratul Gupta 2013-12-10 05:13:13 EST
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.

References:
http://seclists.org/oss-sec/2013/q4/439
Comment 1 Ratul Gupta 2013-12-10 05:16:19 EST
Created python tracking bugs for this issue:

Affects: fedora-all [bug 1039917]
Comment 2 Ratul Gupta 2013-12-10 05:16:24 EST
Created python26 tracking bugs for this issue:

Affects: epel-5 [bug 1039919]
Comment 3 Ratul Gupta 2013-12-10 05:16:28 EST
Created python3 tracking bugs for this issue:

Affects: fedora-all [bug 1039918]
Comment 4 Huzaifa S. Sidhpurwala 2013-12-17 23:03:21 EST
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:

http://www.python.org/dev/peps/pep-0456/

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 02:03:49 EST
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.

Statement:

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.