RE: [PHP-DEV] HashDos protection

From: Date: Tue, 01 Dec 2015 01:28:49 +0000
Subject: RE: [PHP-DEV] HashDos protection
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-89504@lists.php.net to get a copy of this message
Hi Stas, > -----Original Message----- > From: Stanislav Malyshev [mailto:smalyshev@gmail.com] > Sent: Tuesday, December 1, 2015 12:21 AM > To: Nikita Popov <nikita.ppv@gmail.com>; PHP internals > <internals@lists.php.net>; Anatol Belski <anatol.php@belski.net>; Remi Collet > <remi@php.net> > Subject: Re: [PHP-DEV] HashDos protection > > Hi! > > > To fix the HashDos vulnerability for *all* cases (rather than just > > GET/POST parsing), I propose to introduce collision counting during > > hashtable insertion operations. This will throw a fatal error if the > > number of collisions during an insertion operation exceed a certain threshold. > > > > Implementation: https://github.com/php/php-src/pull/1565 > > This looks pretty cool. I'd support making the limit configurable though, is there > a reason why it's not? > From what I was testing, the configuration is not absolutely necessary. The normal usage doesn't seem to cause the situation reproducible by https://github.com/bk2204/php-hash-dos . Even with a big array - with patched PHP I was reaching like 2.5 millions of string keys and gave up. On the other hand, if such a malicious situation would be reached, the application would become unusable - so the configuration is senseless for that case. If the array is big and there are too many collisions, PHP would just iterate over all the buckets all over again looking for a suitable one. Maybe the only case where INI could be useful were to force the exact zero collision or very low collision rate to bail out. At least that was my observation. Regards Anatol

« previous php.internals (#89504) next »