Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:27362
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 66.249.92.170 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=FyRzidKlZkmGRjiXnWuyYfqFdS6KquX+HrMt5FAyD+yMAhi80VI198BaIUXy28tefpi0vKpF4CTvKeVmc1r7iuKv+DDhbevJ/+VvYW2jjA6rCtKPR3DDbGLaHsTvgabY7GOue6hleF8ovkAWusF75gm0IGy/Lwco3FW9vY3vB0M=
Message-ID: <fe05d1540701110814u3f8de1ber4329d9c9c2a6e201@mail.gmail.com>
Date: Thu, 11 Jan 2007 17:14:06 +0100
To: "Stefan Esser" <sesser@hardened-php.net>
Cc: "Rasmus Lerdorf" <rasmus@lerdorf.com>, "Alain Williams" <addw@phcomp.co.uk>, 
	internals@lists.php.net, kel@securityfocus.com
In-Reply-To: <45A6600D.1090500@hardened-php.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20070111144144.GV15998@mint.phcomp.co.uk>
	 <45A65B19.40900@lerdorf.com> <45A6600D.1090500@hardened-php.net>
Subject: Re: [PHP-DEV] Comments on PHP security
From: pierre.php@gmail.com (Pierre)

Hello Stefan,

On 1/11/07, Stefan Esser <sesser@hardened-php.net> wrote:
> Hello Rasmus,
> > There are some concrete suggestions in the article that we addressed a
> > while ago.  Things like:
> >
> >   "I'd like to see new defaults that limit include() and require() to
> >    only allow local files, thereby avoiding remote file injection."
> >
> > That's the default in PHP 5.2.0 which was released over 2 months ago now.
> >
> This is not true. It was demonstrated several times that the
> "protection" is easily bypassed by using data:// or php://input URLs.
> Maybe this is fixed in PHP 5.2.1 but it is not in 5.2.0. And it
> certainly is no protection at all when someone can just use one of the
> other URL wrappers of PHP that are considered safe and put in an
> overlong URL that produces a stack overflow. (Hello zip://)

For your information, zip is not enabled by default. If you have a
bug/issue about the specific zip:// URL, please let me know. Ilia and
Tony already fixed some paths fixes and the fixes are available in
zip-1.8.4. They will be in 5.2.1.

--Pierre