Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:26380
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 72.14.204.234 as permitted sender)
DomainKey-Status: good
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=googlemail.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=m2/mxhNxnff0cbHavWUBbbal0sWwrfOLuYS7Yif/7GChF4ipyERiuLFucmhq2ongQz1FxHhrHFmd52h31qY6vVjeSLpavcygFMlZaEWjHLmLMe8R40uOGUj/Kt+1LIQy2iwUkBja/uAIcQ13MYMqSjCX0npGwQ9jhfmOUFJDnLY=
Message-ID: <10845a340611060055q10748249t66d63c9f53a23f7d@mail.gmail.com>
Date: Mon, 6 Nov 2006 08:55:05 +0000
Reply-To: RQuadling@GoogleMail.com
To: "Peter Brodersen" <penguin@php.net>
Cc: "\"Wez Furlong\"" <kingwez@gmail.com>, "Ilia Alshanetsky" <ilia@prohost.org>, 
	"Rasmus Lerdorf" <rasmus@lerdorf.com>, internals@lists.php.net
In-Reply-To: <164sk2pq9c6spfu094dkfsjme7l5susr58@4ax.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <454C5E50.4030108@zend.com> <454CFAA1.10104@lerdorf.com>
	 <aqvpk2df25h8lc2s6326i8igoh20uj6q1v@4ax.com>
	 <1EA6BEDC-ED17-4FE7-BDB1-B5E5C4FC4BFB@prohost.org>
	 <4e89b4260611050813x42dc16fq74fc6ee240a0038d@mail.gmail.com>
	 <164sk2pq9c6spfu094dkfsjme7l5susr58@4ax.com>
Subject: Re: [PHP-DEV] allow_url_include and php:/data:
From: rquadling@googlemail.com ("Richard Quadling")

I develop solely on and for our Windows network. I regularly use
includes on 2 different servers via \\ rather than a mapped drive.

I can see that adding \\ to the list of restrictions would be an issue for me.

But also, it is a trivial ini update to remove the problem. And it
DOES make PHP more secure.

So, +1 to add \\ to the list of restrictions.

Not so sure it would be as easy for shared host ISPs on Windows to fix
this though.

On 05/11/06, Peter Brodersen <penguin@php.net> wrote:
> Hi,
>
> At first I didn't think there would be an easy solution as it isn't
> possible to distinguish between requests to a "local" SMB server and
> an "outside" server. Both are network requests.
>
> But on the other hand, requesting a file specific via network
> protocols in PHP such as SMB or HTTP or FTP really shouldn't be any
> different. One is asking PHP to perform the network operation to fetch
> a foreign resource.
>
> The key is that administrators would be able to map the needed SMB
> servers as local devices (just as one would mount a NFS share or for
> that sake make an FTP mount) thorugh the operating/file system.
>
> In that case requesting e.g. Z:\file.txt though a device on a SMB
> server share (or a NFS share or a FTP share or ...) would be perfectly
> fine. In that case it would be the operating/file system that is
> performing the network operation (based on central server
> administration) and not some random PHP code (possibly based on user
> input).
>
> Of course, those rare cases where one would actually need to fetch
> files through arbitrary external hosts through PHP one could just turn
> on allow_url_include.
>
> On Sun, 5 Nov 2006 08:13:18 -0800, in php.internals kingwez@gmail.com
> ("Wez Furlong") wrote:
>
> >I think it's a fair assumption that a random host specified in that
> >way be treated as suspicious and lumped in under the
> >disable-includes-by-default category.
> >
> >If someone discovers that it breaks their app, when they read the docs
> >for allow_url_include it should be made very clear what the
> >implications are and what should be done prior to turning it on.
> >
> >So i have no problem with disallowing includes for paths beginning
> >with a double backslash on windows, when allow_url_include is
> >disabled.
> >
> >--Wez.
> >
> >
> >On 11/5/06, Ilia Alshanetsky <ilia@prohost.org> wrote:
> >> I think it'd be wrong to consider networked file system as non-local.
> >> Mostly because many times there are no ways to identify them reliable
> >> and the fact this is a perfectly valid usage that if disallowed by
> >> default would break a large number of applications.
> >>
> >>
> >> On 4-Nov-06, at 4:12 PM, Peter Brodersen wrote:
> >>
> >> > On Sat, 04 Nov 2006 12:40:01 -0800, in php.internals
> >> > rasmus@lerdorf.com (Rasmus Lerdorf) wrote:
> >> >
> >> >> Yeah, we probably should.  Had a chat with Wez about it too.  Here is
> >> >> the patch.  I think this catches the cases we are interested in:
> >> >>
> >> >>  http://lerdorf.com/php/is_url.diff
> >> >>
> >> >> If someone could doublecheck it against those attacks it would be
> >> >> helpful.
> >> >
> >> >
> >> > Would requests to a smbserver, e.g.
> >> > \\10.20.30.40\evil\malicious_php_code.txt be prevented as well? It
> >> > seems like smbserver requests are regarded as part of the default
> >> > filesystem wrapper.
> >> >
> >> > --
> >> > - Peter Brodersen
> >> >
> >> > --
> >> > PHP Internals - PHP Runtime Development Mailing List
> >> > To unsubscribe, visit: http://www.php.net/unsub.php
> >> >
> >> >
> >>
> >> Ilia Alshanetsky
> >>
> >> --
> >> PHP Internals - PHP Runtime Development Mailing List
> >> To unsubscribe, visit: http://www.php.net/unsub.php
> >>
> >>
>
> --
> - Peter Brodersen
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
-----
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&amp;r=213474731
"Standing on the shoulders of some very clever giants!"