[Python-Dev] Hash collision security issue (now public)

[Paul Moore]

On 5 January 2012 19:33, David Malcolm <dmalcolm at redhat.com> wrote:
> We have similar issues in RHEL, with the Python versions going much
> further back (e.g. 2.3)
>
> When backporting the fix to ancient python versions, I'm inclined to
> turn the change *off* by default, requiring the change to be enabled via
> an environment variable: I want to avoid breaking existing code, even if
> such code is technically relying on non-guaranteed behavior.  But we
> could potentially tweak mod_python/mod_wsgi so that it defaults to *on*.
> That way /usr/bin/python would default to the old behavior, but web apps
> would have some protection.   Any such logic here also suggests the need
> for an attribute in the sys module so that you can verify the behavior.

Uh, surely no-one is suggesting backporting to "ancient" versions? I
couldn't find the statement quickly on the python.org website (so this
is via google), but isn't it true that 2.6 is in security-only mode
and 2.5 and earlier will never get the fix? Having a source-only
release for 2.6 means the fix is "off by default" in the sense that
you can choose not to build it. Or add a #ifdef to the source if it
really matters.

Personally, I find it hard to see this as a Python security hole, but
I can sympathise with the idea that it would be nice to make dict
"safer by default". (Although the benefit for me personally would be
zero, so I'm reluctant for the change to have a detectable cost...)

My feeling is that it should go into 2.7, 3.2, and 3.3+, but with no
bells and whistles to switch it off or the like. If it's not suitable
to go in on that basis, restrict it to 3.3+ (where it's certainly OK)
and advise users of earlier versions to either upgrade or code
defensively to avoid hitting the pathological case. Surely that sort
of defensive code should be second nature to the people who might be
affected by the issue?

Paul.