Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:29517
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain chiaraquartet.net from 66.79.163.178 cause and error)
Message-ID: <464DCB8C.90803@chiaraquartet.net>
Date: Fri, 18 May 2007 10:51:40 -0500
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: php-dev <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: potential solution to user streams + allow_url_include=off
From: greg@chiaraquartet.net (Greg Beaver)

Hi,

I think I have a solution that would allow user streams in PHP 6 and
still satisfy paranoid hosters.

First, let me clarify what I see as the assumed problem, so that if I
have missed something, you will correct my assumption:

My assumption:
==============
The point of allow_url_include/allow_url_fopen is to prevent stupid
remote execution vulnerabilities like:

<?php
include $_GET['dumb'];
?>

allow_url_(include|fopen) is not intended to prevent users from
accessing remote sites, as it is still possible through fsockopen() and
other methods to access the outside world.  A firewall is the only way
to truly prevent access to the outside world.

Note that the stream wrapper file:// is a local stream wrapper.  Remote
stream wrappers access the outside world such as http:// ftp:// and
gopher://

The problem:
============
Because there is no way to be sure that a userspace stream is not
remote, all userspace streams are marked as remote and so
allow_url_(include|fopen) applies to them.  As such, because
allow_url_(include|fopen) are disabled by default in PHP 6, this will
effectively kill userspace streams for anything but niche usage.

The solution:
=============
Add a new function: stream_wrapper_set_local()

This function would be used to mark a registered user stream wrapper as
being local, which would allow it to be used.  It would not affect
internal stream wrappers.

Why would this be any different?  The point of the allow_* options is to
make it more difficult to write insecure code.  This would still apply,
as a user would have to explicitly register a stream wrapper as being
local.  This way, our example code:

<?php
include $_GET['dumb'];
?>

would still fail on all the wrappers it should fail on.  The malicious
use of a userspace stream wrapper that is remote would still fail unless
the user explicitly marked it as local.

Paranoid hosters could simply put stream_wrapper_set_local() into the
disable_functions option.

Comments?

Greg