Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:27434
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: <45A9B012.3000903@php.net>
Date: Sat, 13 Jan 2007 22:22:42 -0600
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Stefan Esser <sesser@hardened-php.net>
CC: Marcus Boerger <helly@php.net>, Ilia Alshanetsky <ilia@prohost.org>, 
 Rasmus Lerdorf <rasmus@lerdorf.com>,
 "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> <C9C07D55-09C8-4E9E-82C6-F8B3FE5F7BFB@prohost.org> <904174835.20070113183221@marcus-boerger.de> <45A91AE0.2070407@hardened-php.net>
In-Reply-To: <45A91AE0.2070407@hardened-php.net>
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)

Stefan Esser wrote:
> My 2cents,
> 
> the actually best would be to completely forbid the usage of URLs inside
> include/require and
> introduce a new keyword: include_url that works like the current include
> would work and
> rename allow_url_include into allow_dangerous_urls (for include_url only).
> 
> Basically this would protect everyone from URL includes with no way
> around and if someone
> really really wants this dangerous feature he has to explicitly request
> it via include_url.

Hi,

Although I think this is a decent idea, I would rather see a way that
harmless url wrappers like phar (pecl.php.net/phar and more to the point
pear.php.net/PHP_Archive) that only ever access local files can be more
easily white-listed while even preventing any accidental network access
by pecl extensions.

The include_url solution, although effective, introduces another level
of confusion to an already confusing situation:

include
require
include_once
require_once
include_url
include_url_once
require_url
require_url_once

I had suggested a while back that it might also be possible to use an
internal zend engine flag that is set during a call to include/require
and friends that automatically disables all network access functions
while the stream wrapper open and read of file contents is being called,
prior to parsing the php into opcodes.

This would mean a new zend API function (or macro) would need to be
created that E_ERRORs out if include/require is being called, and it
would need to be inserted in the front of all ftp, curl, pecl/ssh2,
pecl_http, pecl/gopher, fsockopen and whatever else uses the so-called
"internet" that I've forgotten.  Fortunately, the list is finite.  In
this way, user stream handlers could be trusted, as they would simply
not work (uncatchable E_ERROR) if any remote access is attempted.  The
same is true of pecl stream wrappers.  As I recall, the last I heard was
Rasmus said on IRC "that actually might work" and then it was forgotten
by all parties including me. :)

My idea would *not* protect against third-party extensions, but since
these are not distributed with PHP and PHP has no control over them
anyways, I doubt that this will be a real issue, as large hosting
companies are unlikely to install anything third-party except perhaps
Zend Optimizer.

If "include_url" is introduced, it could be a large headache for
PHP_Archive and will be a large headache for pecl/phar.  Perhaps I'm the
only one with this issue, but I think achieving full no-way internet
include is relatively simple without introducing new keywords.

I do like using "dangerous" in the ini settings, that is far more
descriptive and accurate.

Thanks,
Greg