Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89469
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain cubiclesoft.com designates 74.208.222.236 as permitted sender)
To: PHP internals <internals@lists.php.net>
References: <CAF+90c_pVFVbzqThuPg1V3VDTV-7Ci4O6T6hNtY5XPgVb2Mt-Q@mail.gmail.com>
 <CANUQDChV=WRM6WQiNBq4-9JrvwxF_NY5YbGj3-tvgsPgQbc_pg@mail.gmail.com>
 <CAF+90c9GNzszV-nKfzD=1SGLpJoAfNtok45p7sSQz9A5TqdAdg@mail.gmail.com>
Message-ID: <56588DBA.9070209@cubiclesoft.com>
Date: Fri, 27 Nov 2015 10:07:06 -0700
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120327
 Thunderbird/11.0.1
MIME-Version: 1.0
In-Reply-To: <CAF+90c9GNzszV-nKfzD=1SGLpJoAfNtok45p7sSQz9A5TqdAdg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] HashDos protection
From: thruska@cubiclesoft.com (Thomas Hruska)

On 11/27/2015 9:12 AM, Nikita Popov wrote:
> 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

I don't know if anyone has suggested this before, but why not have a 
function that application developers can call to switch hash modes and 
support multiple hash modes in the core?

I've always viewed 'max_input_vars' as an emergency hack and I've run 
into the default 1,000 limit many times.  When I hit that limit, I 
inevitably have to raise it to anywhere from 3,000 to 10,000 to get the 
target application to function, which, of course, puts the whole server 
at risk.

If the application developer could declare what hash mode to use for new 
arrays, that could potentially solve the problem more cleanly.  SipHash 
would be used for security scenarios (PHP loading of superglobals, user 
input, etc.) and the current DJB hash for everything else.  That could, 
of course, lead to unfortunate situations.  Alternatively, default to 
SipHash for everything but the application developer could turn it off 
and on as needed at runtime.  Put a warning in the documentation about 
the security of hashes and also mention leaving SipHash enabled when in 
doubt.

-- 
Thomas Hruska
CubicleSoft President

I've got great, time saving software that you will find useful.

http://cubiclesoft.com/