On Tuesday 20 March 2007 02:07, Alan DuBoff wrote: > On Monday 19 March 2007 07:37 pm, Stefan Teleman wrote: > > http://www.php-security.org/ > > This is scary...I think I'll go get a cold shower...;-) > > I have to wonder, much of the online forum software is written in > PHP, and as such seems to be vulnerable. How do people deal with > sites that are based on that?
Numerous sites are written in PHP. Many of them run the suhosin security extension, but many others don't. Those who don't are doing so at their own peril. php-security writes the suhosin PHP security extension, which is very useful (imho it would be insanely risky to run any PHP site open to the Internet without suhosin enabled). The constant problem php-security is facing is that they update their security extension depending on the latest vulnerabilities they have uncovered. So it ends up being a game of a catch-up: PHP releases a new version, php-security has to update the suhosin extension to this latest version. > I mean, you have to patch this stuff constantly, so no matter what > is delivered will be changing shortly it would seem. Essentially, yes. It looks like there will always be two parallel patch tracks: security patches for the currently released PHP, and security patches for the next-to-be-released PHP version. All this is compounded by the fact that PHP releases aren't necessarily compatible with each other. > Truely the only way to deal with that is to be tracking the nightly > code from PHP, or is there another way? The fundamental problems stems from the fact that a PHP vulnerability can exist either in the PHP code, or in the PHP application. Uncovering vulnerabilities in the PHP code can be very tricky: vulnerabilities might only occur on infrequent code paths, or in infrequent combinations of code paths + PHP extensions being used. Vulnerabilities in the PHP application depend exclusively on how the application is written. I'm thinking that the nightly code would be even more dangerous. It's also a moving target. It seems to me that the efficient approach is to track official PHP releases. The official (numbered) PHP releases are the only ones which might have a release of suhosin. What i believe we should do: we should audit the PHP codebase with Coverity (http://www.coverity.com/). From looking at the htp://scan.coverity.com/ page, it doesn't look like PHP is currently being audited by Coverity. The only information i could find about a PHP Coverity audit was here: http://www.internetnews.com/dev-news/article.php/3589361 "Perl had a defect density of only 0.186. In comparison Python had a defect density of 0.372 and PHP was actually above both the baseline and LAMP averages at 0.474." [defect density == number of code defects per 1000 lines of code] I believe we should also Purify PHP. The problem is that Purify probably won't work on Nevada, but we could build PHP on a release of S10 they support, and it will still catch buffer overflows, ABR/ABW, UMR, stack corruption, double deletion, etc. We could then publish the results of the Coverity audit and of the Purify output, and we could forward them to php-security.org, along with patches. This would give the PHP community an objective base for requesting bug and security fixes. > Seems we'll need to update this regularly as a community. Not > pointing the finger at you specific Stefan, it's an issue that > needs to be worked out within the community. The most important aspect, for me, is to identify these vulnerabilities and to have bugs and security fixes accepted upstream by the PHP Group. --Stefan -- Stefan Teleman 'Nobody Expects the Spanish Inquisition' KDE e.V. -Monty Python [EMAIL PROTECTED] _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
