Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:17005
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <42C2AD81.8060609@townnews.com>
Date: Wed, 29 Jun 2005 09:17:37 -0500
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
MIME-Version: 1.0
To: internals@lists.php.net
References: <42BDDC82.6020208@ohgaki.net>	<17088.52397.92440.326561@desk.crynwr.com>	<42C0CF76.6090203@lerdorf.com> <42C0F4DA.4000605@php.net>	<17089.18702.450236.614561@desk.crynwr.com>	<42C225F7.1060201@lerdorf.com>	<17090.14242.815242.149673@desk.crynwr.com>	<Pine.LNX.4.61.0506290919310.17486@arfg.argcubovn.sv> <3br12t95.fsf@random.internal>
In-Reply-To: <3br12t95.fsf@random.internal>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] allow_url_fopen should be INI_ALL
From: sthomas@townnews.com (Shaun Thomas)

Derrell.Lipman@UnwiredUniverse.com wrote:

>> Please troll, do you go away if I close my eyes?
> 
> That's not fair.  Russell is providing strong arguments and rebuttals
> for every point.  You may not agree with his points, but what he's
> doing is not trolling.  This discussion seems to have strong backing
> on both sides of the issue.

While I'd like to agree with this, all I see when reading the group is a
week-long simmering flame war that boils down to "OMGWTFBBQ!!!!11!11one
inc1ud3 is teh 5pl0i7z!!!1111"

Rasmus says "These security articles are pretty old," and gets back the
response of "yeah, well you're implying Google doesn't return good
results!"  This is trollish behavior any way you slice it.

Should exec, system, and shell_exec filter commands that could be
harmful?  Should they make sure nobody runs "rm -rf /" on your server
because somebody did a system($foo)?  PHP gives all system
administrators the tools they need; whether it be safe_mode,
safe_mode_exec_dir, open_basedir, disable_functions, allow_url_fopen,
and other methods of locking down a server to avoid accidental or
malicious damage.

For what it's worth, I agree that include should have a method of
disabling fetching remote files.  We actually patched PHP to this effect
after one of our users did include($foo) and got us hacked.  We still
allow_url_fopen for stuff like RSS feeds, but none of this "include and
evaluate" crap for us.  We run a hosting service filled with users
ignorant of the true power at their fingertips, people who either don't
read the manual or misunderstand it.  PHP is a programming language used
by non-programmers, and *that* is what makes it dangerous.

Why do I say this?  People get attached to a method for doing something.
  Some of our users were *convinced* they had to execute remote code from
another site (which we also host; they didn't seem to understand the
idea of including without http://).  So what did they do?

$bar = file_get_contents($foo);
eval($bar);

Does PHP have to stop this, too?

As it turns out, our particular combination of safe_mode_* elements
means users only get access to their own files, can only execute
binaries we allow, and we explicitly disable any function that returns
system information, provides shared resources, or is capable of
modifying permissions.  If one of our users is sloppy, only their own
files are at risk, and we have backups in any case.

Railing on for days at a time at how include is insecure is not news,
and accomplishes nothing.  The main core developers have had their say,
and they're not going to change their minds through constant harassment;
that's just not human nature.

That said, I humbly ask we add allow_url_include to accompany
allow_url_fopen, since some desire only to disable the former.  We got
what we wanted by patching the source, so do as you will.  ^_^

-- 
Shaun M. Thomas                INN Database Administrator
Phone: (309) 743-0812          Fax  : (309) 743-0830
Email: sthomas@townnews.com    Web  : www.townnews.com