Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83704
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.42 as permitted sender)
Message-ID: <54ECF605.7030506@gmail.com>
Date: Tue, 24 Feb 2015 14:07:01 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: =?UTF-8?B?UMOhZHJhaWMgQnJhZHk=?= <padraic.brady@gmail.com>
CC: Dmitry Stogov <dmitry@zend.com>, Yasuo Ohgaki <yohgaki@ohgaki.net>, 
 "internals@lists.php.net" <internals@lists.php.net>,
 Nikita Popov <nikitappv@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>
In-Reply-To: <CALwr1GkY_8TN-HwXnRNL0-1oRfQPJvz0_vyJv_ojUTVsFbkNTQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Script only include/require
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> They'd need to upload with a matching file type. Instead of any file

Not sure what you mean by that. phar can read tars, etc. AFAIK, can't
it? Also, phar archive has no requirement of being named something.phar,
afaik can be also named cuteponies.gif. E.g., I just did this:

1. Created file chump.php:

<?php

include $argv[1];

This is an idealized vulnerable script.

2. Created file pwnd.php
<?php

echo "pwnd!";

This is an idealized exploit.

3. Put it into an archive:
tar cvzf cuteponies.gif pwnd.php

4. Run this:

php -dallow_url_include=0 chump.php phar://cuteponies.gif/pwnd.php

The output is:

pwnd!

I'm not sure how this measure would protect from such scenario. Am I
missing something here?

> This is not even remotely magic quotes. No input is altered.

Don't be so literal. It's not about altering input, it's about the fact
that it breaks stuff and not adds much to security.

> None of this detracts from limiting file includes. Other potential

Not sure what you mean. If you can pull off file include - which is a
precondition of this feature being useful - then you can pull off phar
include.

> weaknesses could be addressed separately if you agree there's more than
> one addressed not addressed here. One might say...incrementally.

The problem is there's no increment there. It's like having a password
hardcoded to "password". You can say "oh, it's incremental security, at
least we have a password!" but it is not incrementing the actual security.

> You keep mentioning magic quotes. That was never an improvement. It was
> removed from PHP. Please stop trying to associate two unrelated things

Yes, it was removed from PHP - exactly because it did not produce the
attempted improvement in security. This feature is of the same kind - it
tries to produce increase in security but fails. Thinking of it as a
security feature would produce nothing but an endless stream of CVEs
with PHP name attached to it. Not a good idea.
-- 
Stas Malyshev
smalyshev@gmail.com