Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:29652
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain l-i-e.com from 67.139.134.202 cause and error)
Message-ID: <48108.216.230.84.67.1179792921.squirrel@www.l-i-e.com>
In-Reply-To: <7d5a202f0705190242haca6793i81564178f6d8ed21@mail.gmail.com>
References: <464DCB8C.90803@chiaraquartet.net>
    <7d5a202f0705181813l221248cdu85197a82a1ee4227@mail.gmail.com>
    <464E5856.5000901@zend.com>
    <7d5a202f0705190242haca6793i81564178f6d8ed21@mail.gmail.com>
Date: Mon, 21 May 2007 19:15:21 -0500 (CDT)
To: "Cristian Rodriguez" <judas.iscariote@gmail.com>
Cc: internals@lists.php.net
Reply-To: ceo@l-i-e.com
User-Agent: Hostbaby Webmail
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Importance: Normal
Subject: Re: [PHP-DEV] potential solution to user streams + 
     allow_url_include=off
From: ceo@l-i-e.com ("Richard Lynch")

On Sat, May 19, 2007 4:42 am, Cristian Rodriguez wrote:
>>2007/5/18, Stanislav Malyshev <stas@zend.com>:
>> Sane hosters do not rely on general-purpose language to provide
>> security, they use OS and hardware designed for exactly that
>> purpose. ;)
>
> unfortunately hosters has to equilibrate security vs/usability for
> their customers.. so disaloowing 100% access to outside world is
> frecuently not possible.
>
> The issue with this remote url include thingy is that is hard to find
> a valid use case ..does anyone has a **real** one ? why it was
> introduced in the first place..?? no, Im not talking about crippling
> the language for security reasons as some may argue..my point is this
> "feature" in the reality causes far more harm than good and it has
> become one of the top ways to attack applications since it's
> introduction..my intention is only to make people think if the hassle
> of adding new ini directives (like allow_url_include) or functions is
> worth. maybe with PHP6 this issue can be addressed from it's roots
> instead of adding yet another workaround.

The main problem, I think, is that you are looking at allow_url_fopen
as a "Feature" somebody added, rather than as a side-effect of having
the base common code of include and fopen both working through the
same low-level functions.

Remote URL 'include' mostly "works" because it basically just calls
the C-equivalent of eval(file_get_contents()) -- the guts of include
and the guts of the basic file-reading code are the same code...

So it's either:
A) Re-write include from scratch to not use the same basic
file-reading functions as the rest of PHP uses.
B) Hack a black-list approach to disallow include() to use "remote"
files.

Unfortunately, A) is a ton more work than B), even if everybody
recognizes that B) is not necessarily the "best" answer.

And, in fact, B) is now having some false-positive (false-negative?)
side-effects of disallowing things like 'phar' from working, even
though it should work.

This is not a trivial "change one line of code" fix.

It's endemic to include and stream functionality, and there are pros
and cons to the various solutions being batted around.

I suspect that there *are* valid uses of remote include, and have
posted a couple (admittedly somewhat lame ones) already.  I'm suspect
people who actually USE the feature have more realistic needs...  But
perhaps not.

Even if nobody in the world *needs* the feature, and could re-code
their application to not use it, there are a lot of scripts that use
it, some more wisely than others...

But it seems like people are so polarized on this topic, and their own
views are so ingrained, that nobody is even willing to recognize that
other positions are valid, so we have an endless parade of "only my
answer is correct" here.

That is not effective communication, nor useful discourse, imho.
[insert Monty Python argument skit here]

Of course, suggestions with actual PATCHES to "fix" the problem in
whatever way the poster sees fit, and a shoot-out of testing those for
vulnerabilities and usablity would be most welcome. :-)

-- 
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?