Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:83875
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.53 as permitted sender)
Message-ID: <54EEDE8E.6070201@gmail.com>
Date: Thu, 26 Feb 2015 00:51:26 -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: Yasuo Ohgaki <yohgaki@ohgaki.net>
CC: "internals@lists.php.net" <internals@lists.php.net>
References: <CAGa2bXbt9FAdRtW1GxDyT+G-4bWBACTso_DOizcSHmmgmSVtmA@mail.gmail.com> <CAGa2bXb5QEKOggRbUnmVHuib=P_tJ9_W+QyMa_SCpc7RmSCgSA@mail.gmail.com> <54EE50CF.9090508@gmail.com> <CALwr1GmoAxfbKvJYVLeL3wPXEKKbu1jKGkTFcG0KQ_Ogx172sA@mail.gmail.com> <54EE5A39.9040401@gmail.com> <CAGa2bXYWQCZA8_-EpQcb_Af7DT-_FV7HdfAHZrVt4V7i7vEURg@mail.gmail.com>
In-Reply-To: <CAGa2bXYWQCZA8_-EpQcb_Af7DT-_FV7HdfAHZrVt4V7i7vEURg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: [RFC][VOTE] Introduce script only include/require
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> This can be prevented by restricting phar archive name or forbid all
> URI name at all. The latter is better choice.

If by "all uri" you mean all streams, that would be very high burden,
which may break many applications using streams, including phar handling.

> There is design problem obviously. The reason why phar:// is allowed is 
> that "allow_url_include" is not INI_ALL. 

The reason why phar is allowed is because phar is not a remote stream,
so access to phar is the same as access to local file system, which is
necessary for include anyway. The contents of phar is in the same domain
as contents of local filesystem, that's why no distinction is made.

> Script cannot change the setting, therefore special phar:// is needed to 
> be allowed unconditionally. I would say INI_SYSTEM for allow_url_include
> is false sense of security. It introduced security issue like you've
> mentioned.

It doesn't introduce any issues, unless you declare there should be
distinction between files on the filesystem, which is needed to make
your approach useful. But I do not think it's a good security - trying
to allow including user-controlled files securely is IMO a futile task.
The problem should be fixed at the root - by not having such includes
that allow arbitrary filenames injected by user.
-- 
Stas Malyshev
smalyshev@gmail.com