Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89504
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error)
To: "'Stanislav Malyshev'" <smalyshev@gmail.com>,
	"'Nikita Popov'" <nikita.ppv@gmail.com>,
	"'PHP internals'" <internals@lists.php.net>,
	"'Remi Collet'" <remi@php.net>
References: <CAF+90c_pVFVbzqThuPg1V3VDTV-7Ci4O6T6hNtY5XPgVb2Mt-Q@mail.gmail.com> <565CD9E2.7030501@gmail.com>
In-Reply-To: <565CD9E2.7030501@gmail.com>
Date: Tue, 1 Dec 2015 02:28:49 +0100
Message-ID: <01d101d12bd7$a44f79d0$ecee6d70$@belski.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQEkNhkZaWBBMPbsdhih7rI8XPIJCAHebNrYoABNZmA=
Content-Language: en-us
Subject: RE: [PHP-DEV] HashDos protection
From: anatol.php@belski.net ("Anatol Belski")

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
>=20
> Hi!
>=20
> > 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
>=20
> This looks pretty cool. I'd support making the limit configurable =
though, is there
> a reason why it's not?
>=20
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=20