Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89478
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.193 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <010e01d12978$231e7cf0$695b76d0$@lool.fr>
References: <CAF+90c_pVFVbzqThuPg1V3VDTV-7Ci4O6T6hNtY5XPgVb2Mt-Q@mail.gmail.com>
	<010e01d12978$231e7cf0$695b76d0$@lool.fr>
Date: Sat, 28 Nov 2015 11:34:31 +0100
Message-ID: <CAF+90c_wsXghTbFKGVuh7bKEuu_K0vBUE96sjc=etDbbMrMowQ@mail.gmail.com>
To: Pascal KISSIAN <php-mailing-list@lool.fr>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=94eb2c03623c7e193d0525975a88
Subject: Re: HashDos protection
From: nikita.ppv@gmail.com (Nikita Popov)

--94eb2c03623c7e193d0525975a88
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sat, Nov 28, 2015 at 2:00 AM, Pascal KISSIAN <php-mailing-list@lool.fr>
wrote:

> -----Message d'origine-----
> De : Nikita Popov [mailto:nikita.ppv@gmail.com]
> Envoy=C3=A9 : jeudi 26 novembre 2015 18:25
> =C3=80 : PHP internals; Anatol Belski; Remi Collet
> Objet : HashDos protection
>
> >Hi internals!
> >his mail turned out to be rather long, so I'll start with a TL;DR:
>
> >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 numb=
er
> of collisions during an insertion operation exceed a certain threshold.
>
> >In PHP 5.3.9 a partial fix for the HashDos vulnerability was introduced
> in the form of max_input_vars.
>
> Hi everybody...
> I am very new to this mailing list, and I do not know If my thinking abou=
t
> this problem is good, but to my opinion, this kind of attack is based on
> the fact that the hacker knows in advance how to compute the hash value i=
n
> order to generate collision.
>
> If a random salt was added in the _zend_array struct (at a cost of the
> salt size 4 bytes? for each hash table),
> Then if  the hash computation takes that salt into account ( add ht
> parameter to each function that calculates the hash)
> It would be impossible to predict the hash of a value.
> So impossible to perform such kind of attack...
>
> What do you think about that ?
>
> Perhaps if you do not want to increase the size of the the _zend_array
> struct, perhaps a random salt initialized at the init of a php program (t=
he
> same for all hash tables, that changes at each run) could be enough!
>

This is what variant 2 (Switch hashtables to a keyed cryptographic hash
like SipHash) describes, using a global per-pool key.

Nikita

--94eb2c03623c7e193d0525975a88--