Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:96128
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain kelunik.com from 81.169.146.220 cause and error)
MIME-Version: 1.0
In-Reply-To: <7426fb32-2eb7-2c65-3cc2-140e16187bb1@gmail.com>
References: <CAKws9z2EWkNNhM7tOMh-_pQ3iLjVj7hbXTB1Hh3a19utPzj-9A@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> <CAEKnhAFhdFdG3v2NpSRqwm3GuVLe=u=LV1bU7Rh+9F6Pjh=R+g@mail.gmail.com>
 <7426fb32-2eb7-2c65-3cc2-140e16187bb1@gmail.com>
Date: Sat, 24 Sep 2016 01:08:14 +0200
Message-ID: <CANUQDCgufNYPuuMGXPypOyTEznAgKBft+DuE2EwE7NwpRYNspQ@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: Jakub Zelenka <bukka@php.net>, Bob Weinand <bobwei9@hotmail.com>, 
	PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113466306fdb29053d34da14
Subject: Re: [PHP-DEV] HashDoS
From: me@kelunik.com (Niklas Keller)

--001a113466306fdb29053d34da14
Content-Type: text/plain; charset=UTF-8

2016-09-24 0:21 GMT+02:00 Stanislav Malyshev <smalyshev@gmail.com>:

> Hi!
>
> > 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).
>
> That can't work well.


It works really well.


> PHP makes a lot of assumptions in short-lived
> requests, and assuming the same request lives forever is bound to cause
> a lot of issues - from stale objects sitting around to unoptimal memory
> use to eventual overflows in all kinds of counters, etc.


It's not long running requests. They're just CLI apps.


> Why not use
> real servers for server work?
>

Performance. Bootstrapping everything on every request is very, very
resource aggressive.


> You yourself say you'll have it behind nginx or so - so why not let
> nginx do the server part?
>

You don't have to run it behind Nginx at all. Most often you do it, because
you have other (traditional) apps on the same server.


> We have several hundred places in PHP where fatal error (E_ERROR or
> E_CORE_ERROR) can be produced.


None of these should be triggerable by user input if you do it right.


> Of course, some of them are compile-time
> but not all of them. E.g., various string overflow scenarios can be
> triggered by combining or processing strings (such as uncompressing or
> decoding various formats).


Uncompressing files shouldn't be done in web requests anyway. It's best
pushed to a queue and processed by workers then.


> If you server relies on proxy to filter out
> all fatal error scenarios, I'm afraid it's much harder than it seems.
>

We don't.


> I of course do not propose to make nginx filter JSON data. On the
> contrary, I propose when we have clearly malicious DoS attempt (like
> string overflow or hash collision overflow) to fail fast instead of
> trying to make right and playing whack-a-mole. We have enough fails in
> this are already.


Again, user input shouldn't be able to trigger unrecoverable fatal errors.

Regards, Niklas

--001a113466306fdb29053d34da14--