Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:26384
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 66.249.82.235 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=ZN69dCL4/YIR+wdl/w2qYzeVu/8vchSL/4M+ldPuWZH54UIF/lwSaJ1LRufCdQdBVyc7Y2qIcCxSp9/zkg8BnHfeReghs6qFcz36nUDxcn66is1ul/hOJqGdXhgJ+ZfYlblIzfrfZXo/1hPsgMY4dbtEt2P/z4WpGV+7hql6aAg=
In-Reply-To: <454EA9AD.3030701@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> <8D0283BB-3656-410E-85CC-C38F3D708A22@prohost.org> <454EA9AD.3030701@zend.com>
Mime-Version: 1.0 (Apple Message framework v752.3)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-ID: <BB9CB2FA-777F-48ED-8ED8-8745A9BAA9F4@prohost.org>
Cc: internals@lists.php.net
Content-Transfer-Encoding: 7bit
Date: Mon, 6 Nov 2006 11:25:18 -0500
To: Stanislav Malyshev <stas@zend.com>,
 Rasmus Lerdorf <rasmus@lerdorf.com>
Sender: Ilia Alshanetsky <iliaal@gmail.com>
Subject: Re: [PHP-DEV] allow_url_include and php:/data:
From: ilia@prohost.org (Ilia Alshanetsky)

Well, it looks like the overall consensus is that we add this  
restriction, so let's add in it. It seems I am the only one somewhat  
against it...


On 5-Nov-06, at 10:19 PM, Stanislav Malyshev wrote:

>> 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.
>
> How many apps really need to import includes from foreighn systems  
> which aren't mounted as drive letters? I don't think anybody does  
> (or should) build an applications like that.
>
>> 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.
>
> Sure, we need to consider that - I think that's exactly what we are  
> doing now :) My assessment would be people usually don't do that  
> purposefully, but you and everybody on the list are welcome to give  
> examples to the contrary of course.
>
>> 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
>
> SMB can be as anonymous as HTTP. The reason why HTTP is used more  
> because you can easily buy HTTP hosting solution and SMB hosting  
> would probably cost more, and because HTTP is much more known and  
> easy to set up right to the script kiddies of all kinds. But once  
> people figure out something can be hacked through SMB means, they  
> would write a script to do it and script kiddies would do it as  
> easily as anything. Once writing an exploit was are that few could  
> master, now there are ready-made rootkits for any vulerability out  
> there for anybody to use.
>
>> 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.
>
> "Pwned" windows boxes are not unheard of, to say the least. :) And  
> any unix can do smb as good as windows, thanks to samba team ;)
>
>> A firewall rule can be used to block outgoing smb connections  
>> quite easily on both linux and windows.
>
> Yes, sure - though standard config does not block that AFAIK and  
> the whole point of allow_url_include is to protect such configs as  
> far as I understand.
>
> -- 
> Stanislav Malyshev, Zend Products Engineer
> stas@zend.com  http://www.zend.com/
>
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Ilia Alshanetsky