[Python-Dev] Status of the fix for the hash collision vulnerability

[Tim Delaney]

On 17 January 2012 10:14, Tim Delaney <timothy.c.delaney at gmail.com> wrote:

> On 17 January 2012 09:23, Paul McMillan <paul at mcmillan.ws> wrote:
>
>> This is why the "simply throw an error" solution isn't a complete fix.
>> Making portions of an interface unusable for regular users is clearly
>> a bad thing, and is clearly applicable to other types of poisoned data
>> as well. We need to detect collisions and work around them
>> transparently.
>
>
> What if in a pathological collision (e.g. > 1000 collisions), we increased
> the size of a dict by a small but random amount? Should be transparent,
> have neglible speed penalty, maximal reuse of existing code, and should be
> very difficult to attack since the dictionary would change size in a (near)
> non-deterministic manner when being attacked (i.e. first attack causes
> non-deterministic remap, next attack should fail).
>
> It should also have near-zero effect on existing tests and frameworks
> since we would only get the non-deterministic behaviour in pathological
> cases, which we would presumably need new tests for.
>
> Thoughts?
>

And one thought I had immediately after hitting send is that there could be
an attack of the form "build a huge dict, then hit it with something that
causes it to rehash due to >1000 collisions". But that's not really going
to be any worse than just building a huge dict and hitting a resize anyway.

Tim Delaney
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20120117/6e6e558a/attachment.html>