Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:57293
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain nopiracy.de from 81.169.146.162 cause and error)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: multipart/signed; boundary="Apple-Mail=_B2CB745F-676D-4D3E-AA8C-1CE1BB6F0E9C"; protocol="application/pgp-signature"; micalg=pgp-sha1
Date: Mon, 9 Jan 2012 17:18:38 +0100
In-Reply-To: <CAF+90c8ajB0RUnEGHxo-sjYh+YZCkqaXGE7e-3YX11PCvSZ+uw@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
References: <CAEZPtU44aag3z-oGAx+mF1dvr9qF0ZLpdW3pHFWEe0uwbchMBQ@mail.gmail.com> <CAF+90c8ajB0RUnEGHxo-sjYh+YZCkqaXGE7e-3YX11PCvSZ+uw@mail.gmail.com>
Message-ID: <ACB36599-E7B4-45F8-889A-223F945D5444@nopiracy.de>
Subject: Re: [PHP-DEV] 5.3.9, Hash DoS, release
From: stefan@nopiracy.de (Stefan Esser)

--Apple-Mail=_B2CB745F-676D-4D3E-AA8C-1CE1BB6F0E9C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Dear Pierre and others,

> I'd strongly suggest to release 5.3.9 (RC5 has been tested now) final
> this week using the max_input_vars fix, with the modification from
> Laruence (but with a larger limit). Laruence addition also fixes
> serialize or json, which are parts that need this fix as well as it is
> impossible to valid a string manually (length check only is not enough
> or cannot work in all cases).

Why do you advocate a patch from Laruence that randomizes the size of =
the HashTable, which does not fix the HashDOS security problem at all?

It seems that the majority of people working on this HashDOS stuff do =
not understand the actual mathematical problem and try to exploit it by =
using numerical indices.

In case of numerical indices a collision is trivial:
0x00010000, 0x00020000,0x00030000, =85 0xFFFF0000 will all collide =
because n mod 2^x is always 0 for x<=3D16.

This is however just the cheap way to cause HashTable collisions in PHP. =
The actual HashDOS exploit the nruns guys were talking about *DOES NOT* =
involve numerical indices at all.
The nruns guys are speaking about collisions in the DJB hash function, =
which is used for alpha numerical indices. This cannot be fixed by =
random HashTable size increments.

Random HashTable size increments will only lead to tricky debugging =
situations, because due to the randomness the PHP memory layout/usage =
for the same script will be totally different with each run.=20
Just one of the possible consequences: the same script, running on the =
same server, called 2 times with the same parameters can e.g. cause =
memory limit violations in totally different places. Or sometimes does =
not violate the memory limit at all.

And this all ignores the fact that the patch by Laruence is broken and =
performs dangerous operations on the size field that could introduce =
further problems.


*** The only way to fix the HashTable implementation is by using a =
randomized HashFunction (not a randomized HashTable) ***
*** And of course resource limits are always a good addition to protect =
against this and future different vulnerabilities. ***


Regards,
Stefan Esser=

--Apple-Mail=_B2CB745F-676D-4D3E-AA8C-1CE1BB6F0E9C
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iEYEARECAAYFAk8LE18ACgkQSuF5XhWr2nhK5wCgsdC+YSM15tOw4xHGmBoQTuxg
t8cAn0d1OEsVJn+JSNS04hhPy/KLEMFS
=5DNs
-----END PGP SIGNATURE-----

--Apple-Mail=_B2CB745F-676D-4D3E-AA8C-1CE1BB6F0E9C--