Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:26367
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 64.233.162.199 as permitted sender)
DomainKey-Status: good
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:in-reply-to:references:mime-version:content-type:message-id:cc:content-transfer-encoding:from:subject:date:to:x-mailer:sender;
        b=ubXbXsVTNKzPGTibsLkYiV7QuRm27YRXTOUHlv1hID7Qwu02yuNY0v69wKxOX6a0jiJi4dNP7XTZRvZ6Iunjhv/cRzcpJumhyQaMl78WpYDdrQiTXexPk7yXdS6t7BP8ZZuNybK6cqFBBsxZmKTIOX90v+0auaZaZQg8OgMkxFA=
In-Reply-To: <454E2BD4.6080601@zend.com>
References: <454C5E50.4030108@zend.com> <454CFAA1.10104@lerdorf.com> <aqvpk2df25h8lc2s6326i8igoh20uj6q1v@4ax.com> <1EA6BEDC-ED17-4FE7-BDB1-B5E5C4FC4BFB@prohost.org> <4e89b4260611050813x42dc16fq74fc6ee240a0038d@mail.gmail.com> <2D1DBDC4-F023-43D1-8A9E-BAB953504BCB@prohost.org> <ps4sk2lcrq4eqmcm3o23bh3q1piko4qsl4@4ax.com> <0936D8A3-72A3-4BD9-8394-AA0BC2193F56@prohost.org> <454E2BD4.6080601@zend.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-ID: <8D0283BB-3656-410E-85CC-C38F3D708A22@prohost.org>
Cc: internals@lists.php.net
Content-Transfer-Encoding: 7bit
Date: Sun, 5 Nov 2006 13:51:29 -0500
To: Stanislav Malyshev <stas@zend.com>
Sender: Ilia Alshanetsky <iliaal@gmail.com>
Subject: Re: [PHP-DEV] allow_url_include and php:/data:
From: ilia@prohost.org (Ilia Alshanetsky)


On 5-Nov-06, at 1:22 PM, Stanislav Malyshev wrote:

> Ilia Alshanetsky wrote:
>> What's to say /drive/smb or letter:// is not an SMB device? Also  
>> why break perfectly valid applications that perform operations on  
>> networked file systems?
>
> Well, it's the same as asking why break valid apps that perform  
> operations on URL.

I guess it is a question of frequency, as a rule a valid use of  
require/include on a URL is quite unusual. From my experience, I do  
not believe the same could be said about smb.

> Because of security policy - i.e., if we choose to have security  
> policy that disallows running code with non-local origin influenced  
> by user data - we must do it full nine yards, not "we won't give it  
> to you by http, but you are welcome to do it by smb".

This is a valid point, but at the same time we need to consider the  
consequences marking of smb:// as url will have on PHP applications  
and weather this is something to be done in a patch level release.  
Exploitation wise all of the hacks I've seen for remote code  
execution were based on http as that provides the best degree of  
anonymity for a hacker, a freehosting page somewhere sending php code  
via  text file. Use of SMB requires a more tricky infrastructure in a  
form of an open smb share, usually meaning an exploited win32 box  
that accepts incoming smb connections.

> Now, if it would be not allowed by default by Windows (AFAIK it is  
> allowed) or there's known way to restrict that from Windows (which  
> I don't know of) - then we may defer this task to the OS, but if  
> there's none, then I don't see how http here would differ from  
> smb... If we say including file from http source is not OK, then  
> why would including file from smb source ok?

A firewall rule can be used to block outgoing smb connections quite  
easily on both linux and windows.

Ilia Alshanetsky