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
