Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83722
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.43 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <54ED085C.8010901@gmail.com>
References: <CAGa2bXa=LHMT+wdSM_xbHDo1901QDSFa-KotjQckNwVX9wUEUQ@mail.gmail.com>
 <CAGa2bXZ0VCC4ZN0=YU8ZE9LXm8m9j-RJnmYOhd5qrENoa1HimQ@mail.gmail.com>
 <CA+9eiLvV-wY-6BC5FHZM=uMAWm4Ny4Ej_m2F31o6DNGacpfJPQ@mail.gmail.com>
 <CALwr1Gmmy06_4ZgsvUhcf5m7g06vK2s18qmxKBv1gu+syrsbQA@mail.gmail.com>
 <54ECD4E3.9040705@gmail.com> <CALwr1GkY_8TN-HwXnRNL0-1oRfQPJvz0_vyJv_ojUTVsFbkNTQ@mail.gmail.com>
 <CAGa2bXZV1FOaW5mJqx2yw7WQz0prp1zfEgdEw99StbWPgDFUwg@mail.gmail.com>
 <54ECFAA8.4020305@gmail.com> <CAGa2bXZ373PGrJtpmgLje3obzGcXQs5sND=8TzyuKac+hZ--Fg@mail.gmail.com>
 <54ED085C.8010901@gmail.com>
Date: Wed, 25 Feb 2015 09:33:44 +0900
Message-ID: <CAGa2bXYDGXu3coifbAdLUqE=1qPEJb4RnC_-vWctcrFirc-S6Q@mail.gmail.com>
To: Stanislav Malyshev <smalyshev@gmail.com>
Cc: =?UTF-8?Q?P=C3=A1draic_Brady?= <padraic.brady@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11c2875a2aa106050fdecc28
Subject: Re: [PHP-DEV] [RFC] Script only include/require
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11c2875a2aa106050fdecc28
Content-Type: text/plain; charset=UTF-8

Hi Stas,

On Wed, Feb 25, 2015 at 8:25 AM, Stanislav Malyshev <smalyshev@gmail.com>
wrote:

> > As far as I know, PHP is the only language that has this type of malware.
> > (Script embedded images) PHP is the only one malware vendors claims
> > it as "PHP malware". This is the fact.
>
> Which type is that? Of course only malware in PHP can be presented as
> "PHP malware", but I don't understand why it is of any significance.
>

I showed Exif specific one as "an" example.

Regardless of your view, people recognizes "PHP is weaker against script
inclusion" because there is "malware works with PHP", but not other
languages.


>
> > The reason is other languages are almost safe by default against script
> > inclusion attacks.
>
> Many languages just don't use patterns like PHP code does - I don't
> think I ever seen Python code doing imports based on variables - I'm not
> even sure it's possible in Python. PHP has more capabilities, but of
> course you need to use them in the right way.
>

To do a similar thing as PHP does, Python needs to read file and parse,
then execute. It's a lot of work compare to "require('file');"

Ruby is a little easier since it allows "full path" script loading. However,
most developers omit file extension. In addition, Ruby does not allow
embedded scripting unlike PHP.

It's much harder to make "Script Inclusion vulnerability" in other
languages.


>
> > This RFC makes PHP safe by default just like other languages +
> > move_uploaded_file()
> > protection.
>
> No, it does not - I've shown the example why. I'm sure there are more.
>

With this RFC

 - require/include only includes ".php" ".phar" by default.
 - move_uplaoded_file() only move files other than ".php", ".phar"
extension by default.

This makes "script inclusion" attack much harder. In fact, this RFC makes
almost
impossible attackers to take advantage of PHP's embed everything nature.


>
> > People do not have to be exparts of developing softwares. Managers will
> > choose illogical choice.
>
> We should not base our decision on the opinions of people we all
> understand are ignorant.
>
> > 1. Anti-virus detects "PHP malware"
> > 2. Managers surprises possible attack (Server takeover)
> > 3. Developers are forced to check their code, since current PHP has no
> > effective script inclusion attack prevention
> >
> > With this RFC, developers can explain this type of attacks cannot be done
> > by PHP's feature. i.e. Exploit servers via script embedded images, etc
> > cannot
> > be done.
>
> I don't think we need to introduce BC-breaking feature in PHP just
> because somebody has a manager that can't understand the basics of
> security.
>

For users do not need these protections, they can simply add one liner.

ini_set('zend.script_extensions', '');

This piece of code is executed for all PHP version without any errors.


>
> > Embedded PHP script uploads are prohibited by this RFC by default.
>
> Only certain very narrow cases of it.
>

Unlike previous RFC, this RFC patch does not care "contents" of file, but
only cares file "extensions". However, it works well as described before.


>
> >
> > PHP became as secure as other languages with respect to script
> inclusions.
>
> You keep repeating that, but it's not the case, and PHP already is as
> secure as other languages - provided you do not use clearly broken code.
> Security of the language is a misnomer anyway - language can not be
> secure (unless it's a language that does nothing useful), only specific
> code can be. Code that allows user-controlled includes without adequate
> filtering is insecure, and pretending that we make it secure does not
> improve security, quite the contrary.
>

I think I explained enough in previous comments.


>
> > Users may shoot their own foot, this is not our issue.
>
> But that's exactly what is required for your change to be useful at all!


Even with this RFC, users can shoot their own foot and PHP is much easier
to do it wrong compare to other languages.

However, if users use new PHP by default setting, PHP is as safe as
other languages against script inclusion/upload attacks. Since we have
move_uploaded_file() protection, PHP becomes safer than others.

 - require/include cannot load script other than ".php"/".phar".
 - move_uploaded_files() cannot move script files ".php"/".phar".

Script inclusion is one of the most severe security breach.
This RFC works well for it.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a11c2875a2aa106050fdecc28--