Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:89479 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 94495 invoked from network); 28 Nov 2015 11:02:47 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 28 Nov 2015 11:02:47 -0000 Authentication-Results: pb1.pair.com header.from=php-mailing-list@lool.fr; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=php-mailing-list@lool.fr; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lool.fr from 212.27.42.3 cause and error) X-PHP-List-Original-Sender: php-mailing-list@lool.fr X-Host-Fingerprint: 212.27.42.3 smtp3-g21.free.fr Received: from [212.27.42.3] ([212.27.42.3:23353] helo=smtp3-g21.free.fr) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id A2/6E-04444-7D989565 for ; Sat, 28 Nov 2015 06:02:47 -0500 Received: from daffy (unknown [82.242.106.155]) by smtp3-g21.free.fr (Postfix) with ESMTP id 1B2ABA6230; Sat, 28 Nov 2015 12:02:13 +0100 (CET) To: "'Nikita Popov'" Cc: "'PHP internals'" References: <010e01d12978$231e7cf0$695b76d0$@lool.fr> In-Reply-To: Date: Sat, 28 Nov 2015 12:02:45 +0100 Message-ID: <014301d129cc$4f97f140$eec7d3c0$@lool.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0144_01D129D4.B15E2E00" X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEkNhkZaWBBMPbsdhih7rI8XPIJCAH/uWNtAc4SvCCf7Lje0A== Content-Language: fr Importance: High Subject: RE: HashDos protection From: php-mailing-list@lool.fr ("Pascal KISSIAN") ------=_NextPart_000_0144_01D129D4.B15E2E00 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =20 =20 De : Nikita Popov [mailto:nikita.ppv@gmail.com]=20 Envoy=C3=A9 : samedi 28 novembre 2015 11:35 =C3=80 : Pascal KISSIAN Cc : PHP internals Objet : Re: HashDos protection =20 On Sat, Nov 28, 2015 at 2:00 AM, Pascal KISSIAN = 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 = number 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 = about 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 in 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 = (the same for all hash >>tables, that changes at each run) could be = enough! =20 >This is what variant 2 (Switch hashtables to a keyed cryptographic hash = like SipHash) describes, using a global per-pool key. >Nikita =20 =20 Sorry Nikita, =20 I didn=E2=80=99t fully read your 1st message because it was speaking on = changing hash algo=E2=80=A6, and I=E2=80=99ve been a bit lazy on = that=E2=80=A6=20 =20 However, I only have thought about a minor change introducing a salt. In the zend_inline_hash_func , hash is initialized with Z_UL(5381) = =E2=80=A6 what about just adding a salt value to this number, this would = not make any performance issue. For hashing integers, why just not adding a salt value also=E2=80=A6 = and no performance issue=E2=80=A6. =20 For storing the salt, if you choose to have one different random value = for each hash table, it would not be a problem for arrays living in = opcache SHM=E2=80=A6 (and hoping that no performance, nor memory issue arise increasing a bit = the size of the hash table) =20 pk ------=_NextPart_000_0144_01D129D4.B15E2E00--