Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83843
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.49 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <54EE50CF.9090508@gmail.com>
References: <CAGa2bXbt9FAdRtW1GxDyT+G-4bWBACTso_DOizcSHmmgmSVtmA@mail.gmail.com>
 <CAGa2bXb5QEKOggRbUnmVHuib=P_tJ9_W+QyMa_SCpc7RmSCgSA@mail.gmail.com> <54EE50CF.9090508@gmail.com>
Date: Thu, 26 Feb 2015 08:07:20 +0900
Message-ID: <CAGa2bXaHNLzuW8+DUU163k1V2wXuyrLLgbqX7gfjjrxtJK077A@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c13bfceb0bfb050ff1b417
Subject: Re: [RFC][VOTE] Introduce script only include/require
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11c13bfceb0bfb050ff1b417
Content-Type: text/plain; charset=UTF-8

Hi Stas,

Thank you for your reply. I understand your view, yet I thought
it's better to share your view with all of us.

On Thu, Feb 26, 2015 at 7:46 AM, Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> > I saw you voted "no".
> > Could you share us the reason behind?
>
> I think I did, in my past messages to the list, but maybe I was not
> clear. I will repeat in short:
>
> 1. I think this RFC does not provide any security improvement, due to
> extreme ease with which the measures in this RFC can be circumvented by
> the attacker.
>

It's secure by default. This RFC protects programs even with most obvious
mistakes like include($_GET['var']);. Since this RFC is simple, there is no
space is left being circumvented by attackers.

2. I think this RFC provides false sense of security for people that
> create vulnerable code and lets them think it's OK to have variable
> includes without adequate safety, since they are "protected" by these
> changes.
>

This is not true. No security standards/guidelines discourage input
validations
regardless of protections existence. We already have NULL byte prevention
and
URI restriction for include/require, these mitigations neither promote
false sense
of security as all of these are "defense in depth".

Besides, the protection can be disabled easily. Smart developers will never
rely on it.

3. I think it causes significant BC break which might be warranted in
> case it provides major improvement in security, but IMO in the light of
> the above it does not provide even minor one.
>

BC is minor. Users can disable protections in various ways while
vulnerability
addressed by this RFC is the most fatal vulnerability. (Arbitrarily code
execution
is the most fatal)

This is why I vote no and call everybody to do the same.


We have simple and effective counter measure proposal against fatal
security breach.
Your reasons are not fatal reason to reject this. It could be hardly a
logical choice. IMHO.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a11c13bfceb0bfb050ff1b417--