Bug 854477 - (CVE-2013-7040) VUL-0: CVE-2013-7040: python: hash secret can be recoved remotely
VUL-0: CVE-2013-7040: python: hash secret can be recoved remotely
Classification: Novell Products
Product: SUSE Security Incidents
Classification: Novell Products
Component: Incidents
Other Other
: P3 - Medium : Normal
: ---
Assigned To: Jan Matejek
Security Team bot
Depends on:
  Show dependency treegraph
Reported: 2013-12-09 12:31 UTC by Sebastian Krahmer
Modified: 2016-04-27 19:09 UTC (History)
1 user (show)

See Also:
Found By: Security Response Team
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Note You need to log in before you can comment on or make changes to this bug.
Comment 1 Swamp Workflow Management 2013-12-09 23:00:35 UTC
bugbot adjusting priority
Comment 2 Sebastian Krahmer 2013-12-10 07:29:28 UTC
Comment 8 Swamp Workflow Management 2013-12-11 14:15:06 UTC
The SWAMPID for this issue is 55400.
This issue was rated as moderate.
Please submit fixed packages until 2013-12-25.
When done, please reassign the bug to security-team@suse.de.
Patchinfo will be handled by security team.
Comment 9 Jan Matejek 2013-12-20 13:41:58 UTC
Upstream only includes the change in Python 3.4 (currently in beta, I plan to update Factory with RC1 scheduled on Jan 19, 2014). There are no plans for backport from their side.

The backport is possible for Python 3, but there are some difficulties - namely, the upstream code might not be entirely stable yet, and I already have trouble tracking what exactly is related to this change.

The change seems to be localized in code, but touches Python's internal hashing mechanism, which affects pretty much everything the interpreter does. IOW, if there is a bug in this, every user of Python will be affected.

As for Python 2, it might be possible to do the backport, but can't guarantee that we retain the original behavior alongside the change. I would have to do the backport and then test whether the original behavior stays the same.
(Remember that in bug 751718, it was decided that we keep the vulnerable behavior as default, for compatibility. Change of hashing mechanism means that ordering of dict keys changes, and hash values for strings change. Although Python does not guarantee that these values are stable, historically they never changed, and code might depend on literal hash values or implicit ordering of dicts. This is mostly an issue for test suites.)

The actual vulnerability can and should be fixed in web frameworks and other exposed pieces of Python code, regardless of whether this is fixed in Python interpreter.

For these reasons, i would like to WONTFIX this issue in released versions, and wait for Python 3.4 where the fix is integrated properly. RedHat also decided to WONTFIX [1].

If that's not acceptable for us, i will try to do the backport. But i am almost sure that i won't be able to hit the Dec 25 headline, and I would like to wait for the Python 3.4 release to be sure that we are shipping the most up-to-date version of the changes in the backport.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1039915
Comment 10 Sebastian Krahmer 2013-12-23 12:21:29 UTC
Ok, given the severity vs. the risk of breaking stuff, I agree.