Semi-closing a hole

Posted Apr 12, 2012 0:13 UTC (Thu) by corbet (editor, #1)
In reply to: Semi-closing a hole by man_ls
Parent article: Python 2.6.8, 2.7.3, 3.1.5, and 3.2.3 security release

I'm not yet sure I agree with the Python developers' decision. That said:

Yes, anybody can run with -R, in which case they only have themselves to blame for anything they break. Doesn't seem like a problem.
If you "stop accepting elements" into a dict, you're going to expose applications to a new exception that they weren't expecting before. That, too, could lead to all kinds of unpleasant behavior. To me, that seems like a more disruptive behavior change than randomizing the hash function.

to post comments

Semi-closing a hole

Posted Apr 12, 2012 8:15 UTC (Thu) by man_ls (guest, #15091) [Link] (1 responses)

I would assume that Python web servers are already prepared to deal with unexpected exceptions anywhere in the process: a simple try...except at the bottom of the request processing chain would be enough.

Perhaps my solution was too naïve, and a cleverer algorithm is required. The original LWN article back from January provided some interesting comments, besides a quickly escalating flame war about sorting algorithms. One of them was "change the hash function at run time if any of the hash chains exceeds a specified length". Or "switch to a balanced binary tree".

The downside would be that DoS prevention would be delegated to code which is seldom used, and which is therefore prone to breaking. But in these days of automated testing this problem could be easily managed by CPython devs. IMHO anything would be better than deferring the decision to the person running the code!

Semi-closing a hole

Posted Apr 12, 2012 14:56 UTC (Thu) by JanC_ (guest, #34940) [Link]

This does not only affect web servers, but any programs that get "untrusted input" in one way or another (which is the majority of all software out there).