Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:29561
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: <464F12EB.30102@php.net>
Date: Sat, 19 May 2007 10:08:27 -0500
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Oliver Block <lists@block-online.eu>
CC:  internals@lists.php.net
References: <464DCB8C.90803@chiaraquartet.net> <200705191234.04424.lists@block-online.eu>
In-Reply-To: <200705191234.04424.lists@block-online.eu>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] potential solution to user streams + allow_url_include=off
From: cellog@php.net (Greg Beaver)

Oliver Block wrote:
> Hello Greg,
> 
> I would first ask the following question:
> 
> Why should the user be prevented to include remote site code?
> 
> #1: hoster and users are equal
> ------------------------------------------------
> 
> The hoster - as the "person" providing for the php infrastructure - is trying 
> to prevent the user (and his own system) - as his partner - from injected 
> code by malicous others.
> 
> #2 hoster distrusts the user
> ---------------------------------------------
> 
> By unknown reasons, the hoster thinks that the user is limited in his 
> capabilities and therefore wants to prevent his system from the user.
> ---
> 
> Functions like fsockopen are adding useful features to php. Communication 
> between different systems can be useful. Therefore it should not be disabled, 
> if it cannot be abused easily by 3rd parties.
> I would consider the possibility to inject malicous code by using a query 
> string, as beeing easily achieved.
> 
> In my opinion, your proposal does satisfy #1 not #2. I see no sense though in 
> declaring a local stream as remote. But that's only a question of naming. 
> Wietse Venema called it tainted, as far as I remember.
> 
> I do agree with your assumption that remote code is not malicous in general. 
> But it is susceptible for changes by 3rd parties. There it might be useful to 
> add a feature to sign remote code.

??  My assumption is *not* that remote code is not malicious.  In fact,
anyone developing under this assumption is asking to be attacked.  I
must have been unclear.

My assumption was that the goal of allow_url_include=0 is to prevent
*unintentional* inclusion of remote code, as this is a serious source of
security vulnerabilities.

The problem is that a URL is not inherently remote.  file://blah.php is
for instance obviously a local file.  What is really annoying is that
userspace streams are considered to be remote arbitrarily.  Let's think
about this for a second: if a user is too inexperienced to know they
should never use include with arbitrary user input, what are the chances
they will even *know* it is possible to write a user stream wrapper to
simulate http:// or other remote protocols, let alone know how to do it?

Stanislav's suggestion of auto-disabling allow_url_fopen in a userspace
stream if allow_url_include=1 should prevent the last unintentional hole.

However, it would also be nice if a userspace stream could register
itself as being remote, as this would add another layer of security.
Streams such as http://pear.php.net/HTTP_WebDAV_Client could then tell
PHP not to use them if allow_url_include=0, removing another attack
vector possibility.

Greg