Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:29364
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: <46410298.6000303@chiaraquartet.net>
Date: Tue, 08 May 2007 18:07:04 -0500
User-Agent: Thunderbird 1.5.0.10 (X11/20070306)
MIME-Version: 1.0
To: Stanislav Malyshev <stas@zend.com>
CC: Derick Rethans <derick@php.net>, Marcus Boerger <helly@php.net>, 
 internals@lists.php.net
References: <139872287.20070504170744@marcus-boerger.de> <9DC00D11-00A5-40DB-A397-8454C48FA448@prohost.org> <1525138013.20070504193205@marcus-boerger.de> <463B70A1.4010505@zend.com> <463B7232.7000205@php.net> <463B8B36.5010906@zend.com> <1992195966.20070504214413@marcus-boerger.de> <463B9271.3040009@zend.com> <1348470081.20070504221609@marcus-boerger.de> <463EB3FD.4020009@zend.com> <1062653277.20070507092725@marcus-boerger.de> <463ED871.8080606@zend.com> <463F1B3A.3070703@pooteeweet.org> <463F74EA.7030704@zend.com> <1377895609.20070507211530@marcus-boerger.de> <463F8909.6000709@zend.com> <alpine.DEB.0.98.0705080822260.27587@kossu.ez.no> <46406BE8.7020400@zend.com>
In-Reply-To: <46406BE8.7020400@zend.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Starting 5.3
From: greg@chiaraquartet.net (Gregory Beaver)

Stanislav Malyshev wrote:
>> include to work on those. Making a hack in PHP to allow "phar://"
>> streams to work is a bad idea, a C-extension can easily work here.
> 
> So from now on, every time we would want to user stream we'd have to do
> C extension and all user stream functionality in PHP is just useless?
> And all that for some weird reincarnation on safe mode again? I don't
> know how it sounds for you, but form be it sounds really broken way to
> do things - throwing perfectly good and working userspace streams
> because of pseudo-security configurations.

Hi,

I'd like to remind everyone that I brought up this issue when it was
originally proposed to make userspace streams always remote and to
disable allow_url_fopen/allow_url_include.  This was in the days when
Esser was still around, to put it in context.

The only solution that would allow userspace streams to function *and*
allow security would be to implement safe_mode 2.0: disable all remote
access functions when inside a streams handler.  The implementation is
actually quite simple on the surface, but immensely complex in reality,
as it would require combing through every internal PHP function or class
that can possibly access the outside world, and disabling it.  Otherwise
users will be able to circumvent all_url_fopen by writing a simple
stream wrapper that just downloads the crap and returns it as an $fp.

However, could we take another look at the purpose of
allow_url_include/fopen?  Isn't it to prevent stupid users from shooting
themselves in the foot with code like:

<?php
$a = fopen($_GET['dumbidea']);
include $_GET['waystupididea'];
?>

allow_url_include/allow_url_fopen do not prevent users from downloading
code and executing it intentionally, this is the job of a firewall.

I know the idea of a taint mode was sort of discarded (I think it was,
that was one loooong thread), but realistically, this is probably the
better way to a more secure fopen and include without a more difficult
safe mode-esque solution.

All security experts say security is a tradeoff between convenience and
safety, and the convenience of userspace stream wrappers will simply
disappear in the name of the safety of preventing remote code execution
vulnerabilities.

Thanks,
Greg