Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96060
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CANUQDChQqe3G2xoD4AntUObSGARpFokq7rUWmEM=JX0NOvPCVg@mail.gmail.com>
References: <CAKws9z2EWkNNhM7tOMh-_pQ3iLjVj7hbXTB1Hh3a19utPzj-9A@mail.gmail.com>
 <e741fec3-b301-647c-b24c-dec2fa92554c@gmail.com> <7d5727ba-da33-e3c5-1d1f-318c45d81616@cubiclesoft.com>
 <CAKws9z38_QhH8rnshJu=SP1Aav7jhMnVR2H992+Lse7iMeQ3oA@mail.gmail.com>
 <ffc669b5-8764-3879-0c5a-d047d75c9b45@gmail.com> <CAGa2bXYad=5CNKUR4GTR-uB8L1Gb-2CJk5Fiperz5D_CTL+rxw@mail.gmail.com>
 <9522ebc9-8d8b-045e-b701-02f1166063e6@gmail.com> <CAGa2bXYNZwKrT=Ei8r1DghGjqOGiMUVPEGY31wYK9Hpt+C9XMQ@mail.gmail.com>
 <CANUQDCjcnFdPyG133z6g0DdRLZjUG=+BRhcv4Es9Z+WeoU-Prg@mail.gmail.com>
 <CAFGtT7Zd3+iRuaJtwpML3hO6Kbdu7YtnNOE14zvA78E=QiNprg@mail.gmail.com>
 <40868951-8BDA-4860-884C-B8252C1839E3@gmail.com> <CANUQDChQqe3G2xoD4AntUObSGARpFokq7rUWmEM=JX0NOvPCVg@mail.gmail.com>
Date: Wed, 21 Sep 2016 16:08:45 +0200
Message-ID: <CAF+90c-AWJZA1UPmnYTpdZpX3JLjBNvJ5-BRn5wuMPK1bmu-FQ@mail.gmail.com>
To: Niklas Keller <me@kelunik.com>
Cc: Rowan Collins <rowan.collins@gmail.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=94eb2c034e085dcad1053d051575
Subject: Re: [PHP-DEV] HashDoS
From: nikita.ppv@gmail.com (Nikita Popov)

--94eb2c034e085dcad1053d051575
Content-Type: text/plain; charset=UTF-8

On Wed, Sep 21, 2016 at 3:22 PM, Niklas Keller <me@kelunik.com> wrote:

> 2016-09-21 14:37 GMT+02:00 Rowan Collins <rowan.collins@gmail.com>:
>
> > On 21 September 2016 13:02:20 BST, Glenn Eggleton <geggleto@gmail.com>
> > wrote:
> > >What if we had some sort of configuration limit on collision length?
> >
> > Previous discussions have come to the conclusion that the difference
> > between normal collision frequency and sufficient for a DoS is so large
> > that the only meaningful settings would be on or off. e.g. the proposed
> > limit is 1000, and randomly inserting millions of rows produces about 12.
> >
> > The problem with long running applications is not that they need to raise
> > the limit, it's that they need to handle the error gracefully if they are
> > in fact under attack. Because hash tables are so ubiquitous in the
> engine,
> > there's no guarantee that that's possible, so an attacker would have the
> > ability to crash the process with the limit turned on, or hang the CPU
> with
> > the limit turned off.
>
>
> Another suggestion by Markus Staab is to move the code into the SAPIs and
> have SipHash in CLI and the current hash function in e.g. Apache's SAPI.
>
> Since long running applications use only the CLI, it would be fine for them
> and it wouldn't even need a compile flag.
>
> Regards, Niklas
>

Just so we're clear, switching to siphash is not just a matter of replacing
a hash function implementation. It requires larger changes [1] to support
non-trivial integer hashes which a) change the structure of HashTable
buckets and may have performance impact even if we continue using identity
hashing and b) will definitely lead to changes in the internal hashtable
API, so this may require changes in extensions. (Collision counting on the
other hand is fully transparent.)

Nikita

[1] https://github.com/php/php-src/compare/master...nikic:integerHash

--94eb2c034e085dcad1053d051575--