Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:27361
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 204.11.219.139 cause and error)
Message-ID: <45A66224.8030809@lerdorf.com>
Date: Thu, 11 Jan 2007 08:13:24 -0800
User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207)
MIME-Version: 1.0
To: Stefan Esser <sesser@hardened-php.net>
CC: Alain Williams <addw@phcomp.co.uk>, internals@lists.php.net,
        kel@securityfocus.com
References: <20070111144144.GV15998@mint.phcomp.co.uk> <45A65B19.40900@lerdorf.com> <45A6600D.1090500@hardened-php.net>
In-Reply-To: <45A6600D.1090500@hardened-php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Comments on PHP security
From: rasmus@lerdorf.com (Rasmus Lerdorf)

Stefan Esser 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://)

Yes, this has been fixed.  And I didn't say it was bug free.  Nothing is
ever bug free, but that the feature was introduced.

 >> Another thing to keep in mind is that there are two very distinct
>> security issues here.  Remote vs. Local issues.  Just about every
>> reported security problem against PHP itself has been of the Local
>> variety.  That means that it is a flaw in our various attempts to
>>   
> What a blatant lie. PHP had several bufferoverflows etc... in functions
> often exposed to user input and some direct remote exploits in the past.
> To just name a few: htmlentities() overflow, about a million bugs in
> unserialize(), fileupload exploits, memory_limit exploits, ... Last year
> there was f.e. the zend_hash_del_key_or_index vulnerability that exposed
> a large number of PHP applications to remote attacks. Ah yes and If I
> had not babysitted the CVS in the past there would be even more direct
> remote exploits against PHP, like the HTTP Digest Auth double free
> vulnerability. And yes, only looking at local holes, PHP has more than
> enough of them.

Sure, but the majority were still local.  Some of the local ones can of
course be triggered remotely given the right circumstances which is why
they are still very important to fix.  We fix them as fast as we can and
appreciate any help we get from you and others on this front.

> PS: Stop the "We are secure" marketing and face reality

This isn't "we are secure" marketing.  This is simply explaining what we
are doing to make PHP more secure.

-Rasmus