Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:16987
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
	s=beta; d=gmail.com;
	h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=jrGdQTXn6UJNQQpeLf0mblty9oH4Q/ghWkPtL+gN2LE4HVazxLeOyIkzphSmbK7OGZn3KP0j8CUXqcZjFqrgU/JO8vI7SvZaxP8b5K/vbDf/Yyr1ABWeoO0DL2f0tt7pJhf18LMQlO7JNQMU+0dh2QNWYBXxxIXqvozAq5H6T5I=
Message-ID: <30bd8024050628221159d2e2c2@mail.gmail.com>
Date: Wed, 29 Jun 2005 01:11:11 -0400
Reply-To: =?ISO-8859-1?Q?Nicolas_B=E9rard_Nault?= <nicobn@gmail.com>
To: Russell Nelson <nelson@crynwr.com>
Cc: internals@lists.php.net
In-Reply-To: <30bd802405062822091191c8fc@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
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>
	<1119998580.13690.109.camel@localhost>
	<17089.63833.772427.529013@desk.crynwr.com>
	<42C1FF2A.4000006@fission.org.uk>
	<17090.9316.148303.68882@desk.crynwr.com>
	<30bd802405062822091191c8fc@mail.gmail.com>
Subject: Re: [PHP-DEV] allow_url_fopen should be INI_ALL
From: nicobn@gmail.com (=?ISO-8859-1?Q?Nicolas_B=E9rard_Nault?=)

Just for the records, I guess you all know that I meant 'language
construct' where I wrote 'function' instead (in reference to include).

On 6/29/05, Nicolas B=E9rard Nault <nicobn@gmail.com> wrote:
> PHP is not, in my opinion, idiot-proof. You're right on that point.
> Where our opinions differ is about what should be done about this.
>=20
> If a programmer is not capable of controlling an user input, why then
> should we trust him with anything ? A lot of other functions taking
> user input as arguments could potentially be as damaging as this one.
> I think if a programmer can't read a manual page about a so common
> function, he deserves what he has. Yes, I'm feeling a bit
> pre-conventionnal tonight.
>=20
> As for the `rm -rf /` case, I think it's the best exemple. Why should
> a hacker bother on exploiting an include stupidly called with user
> input unfiltered when he can get straight to an unprotected
> system($_GET['Whatever']). Are you suggesting that virtually _any_
> function should be protected against stupidity ? What kind of language
> PHP would be after that ?
>=20
> On 6/29/05, Russell Nelson <nelson@crynwr.com> wrote:
> > Gareth Ardron writes:
> >  > To me, it's obvious that include includes a file - I see no obvious
> >  > determination that that file is either local or remote in the "inclu=
de"
> >  > statement.
> >
> > Can you name some other languages in which 'include' has such
> > incredibly sharp edges?  C? Python? Perl? BASH? Sed? Awk?  Pascal?
> > BASIC?  Is there *any* precedent for a language in which 'include'
> > will fetch hostile code from a remote server and execute it?  If
> > you're going to argue that experienced programmers will understand
> > that 'include' will fetch code, you should explain how their
> > experience helps them.
> >
> >  > Also, I think it's silly to make include into two functions as you
> >  > suggest given that the ability to include a remote file depends on t=
he
> >  > fopen wrapper being enabled. If we were to follow this line of logic=
, we
> >  > would have two functions for every current one function which can us=
e
> >  > the fopen wrappers.
> >
> > That's not my line of logic, so following it takes you off the map.
> >
> >  > I think the documentation quite clearly states that /all/ functions =
that
> >  > deal with files may deal with remote files if the fopen wrappers are
> >  > enabled
> >
> > Why did both of my users miss that documentation?  The facts seem to
> > be in opposition to your assertion that "the documentation quite
> > clearly states".
> >
> >  > However, as I mention above, every single function that can use
> >  > fopen wrappers can be exploited in this way.
> >
> > Not true.  You would need to have *another* security flaw (a bug in
> > jpg or xml parsing) for hostile jpg or xml content to gain privileges.
> >
> >  > It's unfortunate, but there's a lot of muppets out there who think
> >  > they can code
> >
> > Now you're blaming the victim.
> >
> > --
> > --My blog is at     blog.russnelson.com         | If you want to find
> > Crynwr sells support for free software  | PGPok | injustice in economic
> > 521 Pleasant Valley Rd. | +1 315-323-1241       | affairs, look for the
> > Potsdam, NY 13676-3213  |                       | hand of a legislator.
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>=20
>=20
> --
> Nicolas B=E9rard Nault (nicobn@gmail.com)
> "Maybe nature is fundamentally ugly, chaotic and complicated. But if
> it's like that, then I want out." -- Steven Weinberg (prix Nobel de
> physique, 1979).
>=20


--=20
Nicolas B=E9rard Nault (nicobn@gmail.com)
"Maybe nature is fundamentally ugly, chaotic and complicated. But if
it's like that, then I want out." -- Steven Weinberg (prix Nobel de
physique, 1979).