Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89468
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.194 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CANUQDChV=WRM6WQiNBq4-9JrvwxF_NY5YbGj3-tvgsPgQbc_pg@mail.gmail.com>
References: <CAF+90c_pVFVbzqThuPg1V3VDTV-7Ci4O6T6hNtY5XPgVb2Mt-Q@mail.gmail.com>
	<CANUQDChV=WRM6WQiNBq4-9JrvwxF_NY5YbGj3-tvgsPgQbc_pg@mail.gmail.com>
Date: Fri, 27 Nov 2015 17:12:08 +0100
Message-ID: <CAF+90c9GNzszV-nKfzD=1SGLpJoAfNtok45p7sSQz9A5TqdAdg@mail.gmail.com>
To: Niklas Keller <me@kelunik.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a114904a80d3c3c052587f46c
Subject: Re: [PHP-DEV] HashDos protection
From: nikita.ppv@gmail.com (Nikita Popov)

--001a114904a80d3c3c052587f46c
Content-Type: text/plain; charset=UTF-8

On Thu, Nov 26, 2015 at 8:35 PM, Niklas Keller <me@kelunik.com> wrote:

> Would this be a catchable Error (implementing Throwable) or a real fatal?
> Having a real fatal could lead to a DOS in Aerys as you'd be able to crash
> workers with carefully crafted input variables then.
>

It would be a real fatal error. Throwing an exception in this place would
be problematic, as we're inserting into hashtables all over the place and
not all of these places are exception-safe. Many places also make the
reasonable assumption that (normal) insert operations always succeed.

You are correct in saying that this approach would mean that you can now
easily trigger a fatal error in an application that was previously
susceptible to HashDos (and likely also in some that previously were not).
In most cases this should not be a problem, however for Aerys and likely
other daemons a fatal error implies losing all connections on the current
worker. This may effectively be worse than a HashDos attack.

The only thing I can think to offer here is to make the collision number
threshold ini configurable, so you would have the ability to effectively
disable this protection. In that case you'd have to manually perform size
checks in the right places if you wish to protect against HashDos.

I'm fine with having a solution that only works for the 99% of
applications, until such a time, if ever, as we can feasibly implement one
of the alternative schemes that would cover all possible scenarios.

Nikita

--001a114904a80d3c3c052587f46c--