Month of PHP Bugs Has Begun 165
An anonymous reader writes "The previously announced Month of PHP Bugs started three days ago, and already lists 8 security vulnerabilities in PHP and PHP related software. From the site: 'This initiative is an effort to improve the security of PHP. However we will not concentrate on problems in the PHP language that might result in insecure PHP applications, but on security vulnerabilities in the PHP core. During March 2007 old and new security vulnerabilities in the Zend Engine, the PHP core and the PHP extensions will be disclosed on a day by day basis. We will also point out necessary changes in the current vulnerability management process used by the PHP Security Response Team.'"
Re:Defective by Design? (Score:5, Informative)
It was. A lot of work has been done in the last couple of major versions to fix this, but still a lot of installations are crippled in the name of backward compatibility.
Most of what we're seeing here though is just run-of-the-mill sloppy coding. Create a lot of references to a variable and overflow its (16-bit) reference count? Please. That should never have happened.
Fortunately, it seems most of the bugs released so far don't affect the majority of installations. We have a number of 'executing arbitrary PHP code can let somebody own your web server' -- well, most of us don't let random people run arbitrary PHP code anyway. We have some 'deserialising arbitrary data can let somebody own your web server' issues too, but then there has been a long-standing warning that PHP's deserialise function isn't secure anyway, so that shouldn't affect anyone who's been paying attention. We have some issues with the Zend Platform, but I'm not sure how many people have that installed. So far, the only issue to affect me, is the phpinfo XSS vulnerability -- and that just meant I had to delete my phpinfo.php file that I kept in the root of each domain I host.
Re:Defective by Design? (Score:1, Informative)
Is PHP defective by design?
It was.
It still is. Security is not a property of software, or even software design. It's a property of the development process, and it's something that the core PHP developers have failed to get time and time again.
It's true, they've fixed some glaring problems over the past couple of major versions. But they've done it because they've been nagged and shamed into doing so. They still don't have proper processes in place, they still don't get it, and I'm pretty sure they are going to use the fact that Stefan is the one behind this month of bugs as an excuse to call foul. Sure, they'll fix the bugs because now they have no other option (bear in mind some of these bugs have been known for a long time), but they'll totally avoid thinking about what caused these problems in the first place, and ultimately it will change nothing.
Typical (Score:3, Informative)
I more and more get the feeling that the PHP developers themselves do not properly understand the vulnerabilities any more, which leads to improper and I even dare to say incompetent handling of reports and fixes (many of which simply get applied somewhere down the road without proper announcement or mentioning anywhere in the CHANGELOG) as well as seemingly ignorance regarding more complex vulns that are just as relevant as the glaringly obvious ones but simply not as mass-exploitable by script kiddies.
And *this* is the big problem that PHP is facing today regarding enterprise support. Maybe Jon Doe's blog installation is not as mass-exploitable by a script kiddie any more as it used to be some years ago, yet Big Company's CMS is still vulnerable to complex attacks by an experienced attacker who might use published attacks that security experts know about, yet end users do not.
Re:Defective by Design? (Score:5, Informative)
if you left an open phpinfo() on your server (giving potential attackers access to filepaths, module version numbers, configuration options, apache server configuration options), you have a lot more to worry about than a little XSS.
unfortunatly, you're not alone [google.com].
Re:Defective by Design? (Score:3, Informative)
It may never completely go away, but there are alternatives to using it.
Not really. Most of us in the off-the-shelf web package software development industry are constrained to develop in whatever's available on the servers our clients are likely to choose. An informal survey suggests that of 5 popular hosting providers in my local area, only 1 offers anything other than PHP or Perl/CGI in their basic level package. With this kind of support, we'd be crazy to develop our software in any other environment. Sure, if you're building a site for yourself to use with a hosting provider you can choose, and your budget isn't so tight you have to go with the cheapest available, you get a choice of environments. Most people aren't in that situation -- most people have to use packaged software, and the packaged software vendors are in the same situation I'm in that it is market suicide to use anything other than PHP (or, for a significant minority, ASP.NET).
Re:Oh Nose! (Score:3, Informative)
Re:Oh Nose! (Score:3, Informative)
I've observed that a lot of complaints about modern PHP derive from the fact that it's a dynamic interpreted language, but that in many ways it behaves like a compiled, angry, shoot-yourself-in-the-foot language, like C.
PHP will segfault, just like C, if you recurse too far on the stack, but almost every other scripting language has a mechanism for catching a stack overflow as an exception and then letting the programmer handle it. PHP in this case just crashes; even C allows you to register a function to act if your program has a segmentation violation.
The long-complained-about static binding of class methods to their superclass, and not to child classes is in a similar vein. PHP does what C++ does: static methods execute in the scope of the class they're declared in, and not the class the method is called on. This is a requirement if your language is strict and compiled, like C++, but it's completely superfluous if you're running a dynamic language like PHP. It also makes a lot of tricks used by Ruby and Python developers to make slick frameworks basically impossible.
Re:Defective by Design? (Score:3, Informative)
Also, using something like GRSec [grsecurity.net], or SELinux can further restrict what people could do if they did end up with a shell on your webserver. Although whether it's worth the effort to set up for everyone is another question.