RE: [PHP-DEV] Comments on PHP security

Stefan, do you truly believe that other languages allow for secure shared hosting without using a setuid or chroot solution? I mean take Ruby, Python, Java, C/C++. Can you point out one of them which would not have the issues that PHP has? I think the problem in this case is that shared hosters do not deploy PHP securely. Is this our problem? Yes, I think we need to provide better best practices on how to do it although there is quite a lot of information on the Web on how to do it. In any case, I am planning to write up something more structured so that shared hosters start doing the right thing. The big ones I have worked with actually do have a clue and deploy PHP well. Do we need to provide better tools for our developers? Definitely! This is why we are working on ext/filter (I agree the first pass wasn't very successful), a filter extension in Zend Framework, and other best practices. We have also made significant progress on the core PHP security issues including a coverity code scan (and we are planning to use an additional company), removing flawed features such as register_globals and safe_mode (the latter was never encouraged but I can't blame people for falling into the trap with the crappy name), and many other things. We also have had IBM Research look into various aspects of PHP one of these efforts led to Wietse Venema's suggestion for tainting (which is the main reason why Stefan left the security team as he took that personally because a few years ago he brought up the idea and we weren't in favor). Stefan has a personal vandetta against the PHP Group because we had asked him not to use the PHP brand in the Hardened-PHP patch. This was absolutely not personal but a result of our license. For the same reason Zend does not use PHP in its product names as the PHP license does not allow it. We can not enforce that with projects which are not directly derived from PHP's source code like PHP applications and groups, but Stefan considers we are still following a double standard which we aren't. To be clear, I am not saying PHP doesn't have vulnerabilities. Of course it does. And so do other languages check the bug database of your favorite language and you'll see the segfaults except for languages which don't seem to have an open bug database like Microsoft's and Ruby (I couldn't find the latter). Stefan has actually been very helpful in identifying some of these areas and we have done our best to address them quickly. I hope at some point Stefan is going to channel his knowledge in a more positive way. Andi > -----Original Message----- > From: Stefan Esser [mailto:sesser@hardened-php.net] > Sent: Thursday, January 11, 2007 8:05 AM > To: Rasmus Lerdorf > Cc: Alain Williams; internals@lists.php.net; kel@securityfocus.com > Subject: Re: [PHP-DEV] Comments on PHP security > > 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 > " and the > > > Maybe, if ext/filter would be bug free... > > Stefan Esser > > PS: Stop the "We are secure" marketing and face reality > > -- > PHP Internals - PHP Runtime Development Mailing List To > unsubscribe, visit: http://www.php.net/unsub.php >