Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96094
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.44 as permitted sender)
MIME-Version: 1.0
Sender: jakub.php@gmail.com
In-Reply-To: <9b0fcfa7-f4f8-bac3-5e1e-7e974f217a94@gmail.com>
References: <CAKws9z2EWkNNhM7tOMh-_pQ3iLjVj7hbXTB1Hh3a19utPzj-9A@mail.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> <d2080444-9a17-b3db-89fa-c383155a5756@thefsb.org>
 <CAF+90c-uFg9A2f1SVYTNgjQuFX5PkenrtXd8kf37cYoG0EfgEw@mail.gmail.com>
 <edeb9734-a3d4-bd96-f57c-fa1687473e1b@gmail.com> <CAF+90c9HTpxtY8zeKoOfjdQXTkrVQSw8fb9Ws0-Qs_xmJtttZw@mail.gmail.com>
 <9ce33625-2737-9933-7dd1-4f7930bccfac@gmail.com> <CAEKnhAGg829gi7uEBimZqdd-cTvAn4a1HmjDfEoYeLO93_L2wQ@mail.gmail.com>
 <9b0fcfa7-f4f8-bac3-5e1e-7e974f217a94@gmail.com>
Date: Thu, 22 Sep 2016 10:48:32 +0100
Message-ID: <CAEKnhAF9XGsLqHU5H9aKDA=jWA5iD1ou8UwOX0=OpAC8tnzXdQ@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a114e521e97bf64053d15900e
Subject: Re: [PHP-DEV] HashDoS
From: bukka@php.net (Jakub Zelenka)

--001a114e521e97bf64053d15900e
Content-Type: text/plain; charset=UTF-8

On Thu, Sep 22, 2016 at 10:06 AM, Rowan Collins <rowan.collins@gmail.com>
wrote:

> On 22/09/2016 08:52, Jakub Zelenka wrote:
>
>> I don't like the initial version of the patch that was causing fatal error
>> for json_decode. That's not how json_decode should work. I think that Bob
>> came up later with a better version that was using json recursion error.
>> It
>> might require a bit more work for 7.1 as I changed a json parser since
>> then.
>>
>
> The point of the proposed patch is that it causes fatal error *anywhere*
> that a hash is attacked (and, as discussed, it really is only going to
> trigger on a crafted attack).
>
> Adding mitigations elsewhere such as in the JSON parser can be done *on
> top of* that, since they'll presumably catch the problem before the hash is
> inserted into.
>
> It's the same as if the attack caused an exponential amount of memory
> usage: the engine will bail out as soon as the hard memory limit is
> reached, but extensions can and should detect and avoid scenarios likely to
> cause that.
>
>
Nope the point of the Bob's patch is to use graceful handling with
exception that can be easily checked by the json parser for example! See
https://github.com/php/php-src/pull/1706

From the quick look, it actually just requires regenerating parser from the
json ext point of view.

Cheers

Jakub

--001a114e521e97bf64053d15900e--