Semi-closing a hole

Posted Apr 12, 2012 8:00 UTC (Thu) by man_ls (guest, #15091)
In reply to: Semi-closing a hole by wahern
Parent article: Python 2.6.8, 2.7.3, 3.1.5, and 3.2.3 security release

The correct behavior would be to throw an exception, of course. Instead of collapsing the machine the program would just stop servicing that particular request which has the (n+1)th hash collision.

I don't know much about Python web servers, but I would presume that they are coded so that an exception in a request is caught somewhere and does not affect other requests. (Otherwise the server code is really, really broken: any silly coding mistake becomes a DoS.) If this is the case then you are not back at square one: instead of denying responses for all users you are denying service only to the malicious user, without affecting others. This technique might be called "denial of malicious service".

to post comments

Semi-closing a hole

Posted Apr 12, 2012 9:58 UTC (Thu) by zuki (subscriber, #41808) [Link] (1 responses)

Actually, this idea was tried and rejected (see the discussion attached to the bug in the bug tracker).

The problem is that it is easy to prepare a scenario where the malicious request succeeds but subsequent benign requests fail. For example, the attacker adds 100 usernames which hash to the same value. This works fine because the whole list of usernames is not used during this operation. Then the administrator tries to generate a listing of all user names and hits the limit of 100 collisions and gets an exception in the display code which uses a dictionary to sort the usernames.

Starting to throw exceptions in basically unpredictable places would create a nightmare, where every operation involving a set or dict, which basically means every operation in Python, could potentially fail.

Semi-closing a hole

Posted Apr 12, 2012 12:10 UTC (Thu) by man_ls (guest, #15091) [Link]

Indeed, the bug discussion is very interesting: I just browsed it and people did debate many of the solutions proposed in the recent LWN article.

In the end the simplest solution won, which is not a bad thing in itself -- especially with a security fix, as others have remarked here.