Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:27359
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain hardened-php.net from 81.169.146.188 cause and error)
Date: Thu, 11 Jan 2007 17:04:30 +0100 (MET)
Message-ID: <45A6600D.1090500@hardened-php.net>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Rasmus Lerdorf <rasmus@lerdorf.com>
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>
In-Reply-To: <45A65B19.40900@lerdorf.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Comments on PHP security
From: sesser@hardened-php.net (Stefan Esser)

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://)

> 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.
> In this case you could have a mod_security rule to disallow ../.. style
> patterns in URLs.  But if someone found a way to still sneak that
> pattern through, perhaps because of a bug in mod_security related to
>   
There is nothing more trivial than sneaking something through the
combination mod_security + PHP.

> tag, it might slip through.  Next, ext/filter kicks in with a default
> filter of "special_chars" for example and changes " to &quot; and the
>   
Maybe, if ext/filter would be bug free...

Stefan Esser

PS: Stop the "We are secure" marketing and face reality