[Python-Dev] Status of the fix for the hash collision vulnerability
Gregory P. Smith
greg at krypto.org
Sun Jan 15 02:31:34 CET 2012
FWIW the quick change i pastebin'ed is basically covered by the change
already under review in http://bugs.python.org/review/13704/show. I've
made my comments and suggestions there.
I looked into Modules/expat/xmlparse.c and it has an odd copy of the old
string hash algorithm entirely for its own internal use and its own
internal hash table implementations. That module is likely vulnerable to
creatively crafted documents for the same reason. With 13704 and the
public API it provides to get the random hash seed, that module could
simply be updated to use that in its own hash implementation.
As for when to enable it or not, I unfortunately have to agree, despite my
wild desires we can't turn on the hash randomization change by default in
anything prior to 3.3.
On Sat, Jan 14, 2012 at 11:17 AM, Gregory P. Smith <greg at krypto.org> wrote:
> My patch example does change the bytes object hash as well as Unicode.
> On Jan 13, 2012 7:46 PM, <martin at v.loewis.de> wrote:
>> What an implementation looks like:
>>> some stuff to be filled in, but this is all that is really required.
>> I think this statement (and the patch) is wrong. You also need to change
>> the byte string hashing, at least for 2.x. This I consider the biggest
>> flaw in that approach - other people may have written string-like objects
>> which continue to compare equal to a string but now hash different.
>> Python-Dev mailing list
>> Python-Dev at python.org
>> Unsubscribe: http://mail.python.org/**mailman/options/python-dev/**
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev