RE: [PHP-DEV] HashDos protection
| From: | Anatol Belski | 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