| Summary: | <dev-lang/python-3.4.0: hash secret can be recovered remotely | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Agostino Sarubbo <ago> |
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | normal | CC: | python |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://bugzilla.redhat.com/show_bug.cgi?id=1039915 | ||
| Whiteboard: | A4 [noglsa/cve] | ||
| Package list: | Runtime testing required: | --- | |
It's good to have this captured in a bug, but just FTR we will not clean up 2.7 (and probably not 3.3, either) just because of this bug. Doing speedy stabilization of 3.4 would be neat, but experience leads me to believe that that would also be a pretty unrealistic goal. Upstream tagged this as wontfix for versions older than 3.4 (the latter implemented PEP 456 to address this issue). FOllowing upstream |
From ${URL} : 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 @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.