Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89489
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.48 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: Mon, 30 Nov 2015 11:39:54 +0000
Message-ID: <CABHuAWwasvZFwyY_342yz5-8zzaJdbsKCzGnjkv4PLSbfqoyqA@mail.gmail.com>
To: Pascal KISSIAN <php-mailing-list@lool.fr>
Cc: Nikita Popov <nikita.ppv@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1148e18c00ea250525c080ae
Subject: Re: [PHP-DEV] RE: HashDos protection
From: t.carnage@gmail.com (Chris Riley)

--001a1148e18c00ea250525c080ae
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 28 November 2015 at 01:00, 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!
>
> Best regards,
> Pascal KISSIAN
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
As a bare minimum, such a salt would need to be Xor'd with the string
before hashing simple addition still produces collisions. I suspect it
would still be easy to produce collisions, however my math is not good
enough (at least not on a Monday morning) to figure out how.

--001a1148e18c00ea250525c080ae--