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
Created python tracking bugs for this issue: Affects: fedora-all [bug 1039917]
Created python26 tracking bugs for this issue: Affects: epel-5 [bug 1039919]
Created python3 tracking bugs for this issue: Affects: fedora-all [bug 1039918]
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.
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