Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81995
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.180 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAEZPtU4ThQHcH1hsgYaKwd2yOKAGP7obmcDH15qbDVr6CdgzSQ@mail.gmail.com>
References: <CAGa2bXZMxxXBOQ=NdbNtzgrjjvdomV8zOr+Z4zASZU4+JHmqyw@mail.gmail.com>
 <CAGa2bXbf=hzbZ9eH6JVnMM0+6OeTQvAoqBe44g8qxFAAr9u9Kw@mail.gmail.com>
 <CAG1choq8S_EkdS22SFO+443u_LYVB-Z-b2ra6RK8sDhrJKc-VQ@mail.gmail.com>
 <CAGa2bXbJyK=2GCmGDw7PAh0ib=EL9GO7FFGf0X6VyAWqfR8EAA@mail.gmail.com>
 <CADajX4CHHdSpUfLfjhwrtdzmJfg9di4FpfeVEzBG4P7K7B+e0w@mail.gmail.com>
 <CAPwsocGh_-SYiWceEg=5go8G1bUs+CWUBb9uv_2Oh7AZhBxd8A@mail.gmail.com>
 <CAGa2bXY36wVN50sQ=MTYi+X6664+NYqMhsYFVZ9jeFZ1DXBg9Q@mail.gmail.com>
 <CAEZPtU5=vJG6=cguZfcT6RBriu8GT9vfW=Lqva8-XfEnXzZ23Q@mail.gmail.com>
 <CAGa2bXarZ4A9+HPXniAvBxEtE9KEJTYHHW8aYHCkBsNN5dRNUw@mail.gmail.com> <CAEZPtU4ThQHcH1hsgYaKwd2yOKAGP7obmcDH15qbDVr6CdgzSQ@mail.gmail.com>
Date: Fri, 6 Feb 2015 10:25:43 +0900
Message-ID: <CAGa2bXbWZJ--nkPaskRfCB91wqXSfY7LCwTefVa-ERxaY2r8Nw@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: Leigh <leight@gmail.com>, Adam Harvey <aharvey@php.net>, reeze <reeze@php.net>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c11a9802d5f1050e614f8f
Subject: Re: [PHP-DEV] Re: [RFC][DISCUSSION] script() and script_once()
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11c11a9802d5f1050e614f8f
Content-Type: text/plain; charset=UTF-8

Hi Pierre,

On Thu, Feb 5, 2015 at 8:49 PM, Pierre Joye <pierre.php@gmail.com> wrote:

> PHP is just as safe than the other languages. PHP applicatons maybe
> less, maybe more. I tend to see the amount of attacks as a proof of
> success of a tool instead of a proof of the tool being unsafe (not
> worth attacking 0.01% of the market when you can attack 75%).
>
> > Your proposal requires admins to do the job. It's better to have
> developer
> > option.
> >
> > Do any of you have other preferred option for developers?
>
> We do have one, it is called open_basedir, which I wanted to remove as
> well but we agreed that it has its usefulness. One of them being
> exactly to avoid the inclusion (and display) of critical information.
> It indeed does not prevent one to include and display some text data
> containing passwords or the likes when they are in the open_basedir
> list but still.
>
> And again, if one app allows unvalidated include/require (as in your
> example), it will most likely do fopen and co as well and get data
> displayed one way or another. Using yet another construct will again
> give a false sense of security, solving a real problem using a bandaid
> tape.
>

I agree that user must be careful for any file function. This is not
limited to
include/require.

PHP is unique compare to other languages. PHP allows "script include
statements"
to open files as "script embedded file".

The result is completely different.

 - PHP file exposure and script execution
 - Others syntax error mostly

 PHP == Fatal security issue, Others == Bug.

AFAIK, Ruby/Perl allows script execution with simple file validation. e.g.
Inject code after GIF file signature. However, Ruby/Perl apps were not
reported as vulnerable
to script inclusion because usual image check, e.g. check image size, can
prevent
attack image to be stored. Any other files are failed as syntax errors.

In contrast, PHP allows to embed script anywhere in a file. Image size
check does not
help at all. Converting size does not help also. (e.g. Attacker may embed
script in
color table. Changing size/recreating image cannot prevent attacks) If data
is written
into files, it can be used to execute. *Session data* file can be used to
attack, too.
These are the reason why  file inclusion attacks against PHP applications
are so
popular/common.

Any PHP applications do file upload (image/etc) or data file writes
(wiki/session data) have
much higher script inclusion risk compare to others.

Other languages have fopen/readfile also. In this case, the result is the
same.
PHP is as safe as other languages in this area.

PHP has became as secure as other languages _except_ script inclusion which
allows attackers take over servers. This is what I would like to change.

We have been removed embedded script from regex, i.e
preg_relace/mb_ereg_replace,
because it is dangerous. Why don't we remove embedded script from
include/require.
include/require is used to execute attack script more often than regex.
PHP7 seems
perfect opportunity to me.

Feasible options are
 - Introduce script only inclusion statement. script()/script_once()
 - Change require()/require_once() behavior not to embed script.

Let's have no more script/file inclusion attacks!


Regards,

P.S.  Changing the result of bugs like this is defined as a security
measure by ISO 27000.

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a11c11a9802d5f1050e614f8f--