Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:27443
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain php.net from 66.79.163.178 cause and error)
Message-ID: <45AA961D.4090401@php.net>
Date: Sun, 14 Jan 2007 14:44:13 -0600
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Stanislav Malyshev <stas@zend.com>
CC: Stefan Esser <sesser@hardened-php.net>, 
 Marcus Boerger <helly@php.net>,
 "internals@lists.php.net" <internals@lists.php.net>
References: <F1076B95-2D05-4690-AE84-21FC0552F17A@ch2o.info> <45A8FC49.7050909@hardened-php.net> <45A90809.3050008@lerdorf.com> <45A91002.8020607@hardened-php.net> <526994769.20070113181330@marcus-boerger.de> <Pine.LNX.4.64.0701141301180.32133@mail.zend.com> <45AA116F.7020109@hardened-php.net> <Pine.LNX.4.64.0701141436460.16363@mail.zend.com>
In-Reply-To: <Pine.LNX.4.64.0701141436460.16363@mail.zend.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Comments on PHP security
From: cellog@php.net (Greg Beaver)

Stanislav Malyshev wrote:
> SE>>And If I am not completely mistaken here unlike php://filter a
> SE>>userstream will not give the THIS_IS_AN_INCLUDE_FLAG down to a stream
> SE>>itself opens.
> 
> I think I see what you mean now - i.e. that the user implementation might 
> be tricked into opening URL for include even though direct opening URL for 
> include is not allowed, and since it would do e.g. fopen, it may work 
> around the allow_url_include.
> 
> I would say in most cases prohibiting anything but plain file wrapper for 
> include might be OK, however I know about a number of instances of 
> legitimate wrappers used for include - e.g. archive files like phar and 
> there are other, custom solutions that I saw that use wrappers as base. 
> Maybe it would be a good idea also to pass a flag to stream_open saying it 
> is used for include - though it won't fix broken code of course.

Hi,

There is just such a flag passed to wrapper_open (at least inside pecl
streams, I imagine you're talking about user streams) but that most
likely would not be secure at all, as it puts the onus on the streams
implementor, which is the problem right now.  This is why I suggested
disabling all remote access while calling a stream's open and read for
include purposes, it centralizes the security access inside the zend
engine where it is possible to audit and easier to control.

In my opinion, it would be a pity to lose the design benefits of stream
wrappers in the effort to gain more security when security can be gained
without losing the benefits.  I think it would be good to allow
disabling all urls as Stefan suggested, but if there is a way to
restrict to truly local stream wrappers, I would need to be educated as
to how this is less secure than outright disabling urls.

Greg