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...
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
