Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96118
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.45 as permitted sender)
MIME-Version: 1.0
Sender: jakub.php@gmail.com
In-Reply-To: <67e0478d-534a-1f8a-6b4c-a95573784001@gmail.com>
References: <CAKws9z2EWkNNhM7tOMh-_pQ3iLjVj7hbXTB1Hh3a19utPzj-9A@mail.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> <CAEKnhAF9XGsLqHU5H9aKDA=jWA5iD1ou8UwOX0=OpAC8tnzXdQ@mail.gmail.com>
 <5acaa405-8b76-ce00-1380-614f2f83b549@gmail.com> <CAEKnhAG50eG4RQSRjoZGFkSF_as1DZN5OrBWadyQG-chHDuVhw@mail.gmail.com>
 <d430f3ce-38fe-bfd8-95a0-d78132f9985d@gmail.com> <BLU437-SMTP86FE3BC2E445E56074B889E2C90@phx.gbl>
 <e176001f-0ab7-6d6c-adfe-8d4a31f1337b@gmail.com> <BLU437-SMTP5652D9C5B9D2AC92E4505DE2C80@phx.gbl>
 <b653d6cd-1c3a-f531-4e4f-ccebeefbd3c3@gmail.com> <CAEKnhAHM4k4w2g0cxiNM-RH=_mvWjm8a-m7jdCL63SEvjRYQsg@mail.gmail.com>
 <67e0478d-534a-1f8a-6b4c-a95573784001@gmail.com>
Date: Fri, 23 Sep 2016 21:24:24 +0100
Message-ID: <CAEKnhAFhdFdG3v2NpSRqwm3GuVLe=u=LV1bU7Rh+9F6Pjh=R+g@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: Bob Weinand <bobwei9@hotmail.com>, PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1142d3c47d7fdb053d32906d
Subject: Re: [PHP-DEV] HashDoS
From: bukka@php.net (Jakub Zelenka)

--001a1142d3c47d7fdb053d32906d
Content-Type: text/plain; charset=UTF-8

Hi

On Fri, Sep 23, 2016 at 8:47 PM, Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> Hi!
>
> > That's exactly what we don't want - let the attacker to end our request.
>
> Why not? What else you can do with this request that has clearly bad and
> maliciously constructed data?
>
>
I think there is a confusion about the "servers written in PHP". Those
applications serves more requests in a single (main) PHP request using the
even loop. Good examples of that are Aerys or ReactPHP. So we don't want to
kill that main request if one of the handled requests is malicious (ideally
we just ignore that malicious request and server others).


> > All other things like string overflows and memory limits are under our
> > control (e.g. we can set limit on the server and reject such requests)
>
> Not sure I understand what you mean. How exactly memory limits are under
> your control? If somebody sends a request that blows up your memory
> limit, how you control it? In fact, if somebody sends, say, a POST that
> goes above your post limit - how you handle it without terminating the
> request?


Usually you will have it behind proxy so you can terminate it there if the
request is too big. For example you could set client_max_body_size in
nginx. However we can't effectively catch HashDos by the size because it
can be relatively small request (see nice description of that in one of the
previous emails from Nikita...).

Cheers

Jakub

--001a1142d3c47d7fdb053d32906d--