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

[David Malcolm]

On Thu, 2012-01-05 at 19:34 +0200, Maciej Fijalkowski wrote:
> On Thu, Jan 5, 2012 at 3:39 PM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> > On Thu, 5 Jan 2012 15:26:27 +1100
> > Andrew Bennetts <andrew at bemusement.org> wrote:
> >>
> >> I don't think that's news either.
> >> http://mail.python.org/pipermail/python-dev/2003-May/035907.html and
> >> http://twistedmatrix.com/pipermail/twisted-python/2003-June/004339.html for
> >> instance show that in 2003 it was clearly known to at least be likely to be an
> >> exploitable DoS in common code (a dict of HTTP headers or HTTP form keys).
> >>
> >> There was debate about whether it's the language's responsibility to mitigate
> >> the problem or if apps should use safer designs for handling untrusted input
> >> (e.g. limit the number of keys input is allowed to create, or use something
> >> other than dicts), and debate about just how practical an effective exploit
> >> would be.  But I think it was understood to be a real concern 8 years ago, so
> >> not exactly sudden.
> >
> > That's not news indeed, but that doesn't make it less of a problem,
> > especially now that the issue has been widely publicized through a
> > conference and announcements on several widely-read Web sites.
> >
> > That said, only doing the security fix in 3.3 would have the nice side
> > effect of pushing people towards Python 3, so perhaps I'm for it after
> > all.
> >
> > Half-jokingly,
> >
> > Antoine.

> 
> Just to make things clear - stdlib itself has 1/64 of tests relying on
> dict order. Changing dict order in *older* pythons will break
> everyone's tests and some peoples code. Making this new 2.6.x release
> would mean that people using new python 2.6 would have to upgrade an
> unspecified amount of their python packages, that does not sound very
> cool. Also consider that new 2.6.x would go as a security fix to old
> ubuntu, but all other packages won't, because they'll not contain
> security fixes. Just so you know

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.