Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:89475 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 68739 invoked from network); 28 Nov 2015 01:00:15 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 28 Nov 2015 01:00:15 -0000 Authentication-Results: pb1.pair.com smtp.mail=php-mailing-list@lool.fr; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=php-mailing-list@lool.fr; 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:57619] helo=smtp3-g21.free.fr) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 74/3C-04444-F9CF8565 for ; Fri, 27 Nov 2015 20:00:15 -0500 Received: from daffy (unknown [82.242.106.155]) by smtp3-g21.free.fr (Postfix) with ESMTP id EFD1AA6196; Sat, 28 Nov 2015 01:59:41 +0100 (CET) To: "'Nikita Popov'" , "'PHP internals'" References: In-Reply-To: Date: Sat, 28 Nov 2015 02:00:12 +0100 Message-ID: <010e01d12978$231e7cf0$695b76d0$@lool.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEkNhkZaWBBMPbsdhih7rI8XPIJCKAKf66g Content-Language: fr Importance: High Subject: RE: HashDos protection From: php-mailing-list@lool.fr ("Pascal KISSIAN") -----Message d'origine----- De : Nikita Popov [mailto:nikita.ppv@gmail.com]=20 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.=20 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 Best regards, Pascal KISSIAN