[Python-Dev] [issue13703] Hash collision security issue

[Glenn Linderman]

On 1/26/2012 10:47 PM, Glenn Linderman wrote:
> On 1/26/2012 10:25 PM, Gregory P. Smith wrote:
>> (and on top of all of this I believe we're all settled on having per
>> interpreter hash randomization_as well_  in 3.3; but this AVL tree
>> approach is one nice option for a backport to fix the major
>> vulnerability)
>
> If the tree code cures the problem, then randomization just makes 
> debugging harder.  I think if it is included in 3.3, it needs to have 
> a switch to turn it on/off (whichever is not default).

In case it is not clear, I meant randomization should always be able to 
be switched off.

Another issue occurs to me: when a hash with colliding keys (one that 
has been attacked, and has trees) has a non-string key added, isn't the 
flattening process likely to have extremely poor performance?

Agreed that the common HTML FORM or JSON attack vectors are unlikely to 
produce anything except string keys, but if an application grabs those, 
knows that the user keys are all strings, and adds a few more bits of 
info to the dict for convenience, using other key types, then ...  WHAM?

Seems a bit unlikely, but I know I've coded things along that line from 
time to time... I don't recall doing it in Python Web applications...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20120127/4d1b01df/attachment-0001.html>