March To Be Month of PHP Bugs 292
PHP writes "Stefan Esser is the founder of both the Hardened-PHP Project and the PHP Security Response Team (which he recently left). During an interview with SecurityFocus he announced the upcoming Month of PHP bugs initiative in March." Quoting: "We will disclose different types of bugs, mainly buffer overflows or double free (/destruction) vulnerabilities, some only local, but some remotely triggerable... Additionally there are some trivial bypass vulnerabilities in PHP's own protection features... As a vulnerability reporter you feel kinda puzzled how people among the PHP Security Response Team can claim in public that they do not know about any security vulnerability in PHP, when you disclosed about 20 holes to them in the two weeks before. At this point you stop bothering whether anyone considers the disclosure of unreported vulnerabilities unethical. Additionally a few of the reported bugs have been known for years among the PHP developers and will most probably never be fixed. In total we have more than 31 bugs to disclose, and therefore there will be days when more than one vulnerability will be disclosed."
even if... (Score:3, Insightful)
Re:great... (Score:4, Insightful)
Partially surprising (Score:5, Insightful)
I really shouldn't be surprised at the PHP team's approach to security any more, but it really does still surprise me from time to time. It's amazing, but the PHP team are worse than Microsoft ever were with security. And they don't even learn from this - they've had this attitude for as long as I can remember (PHP 3 days), and they just aren't getting it. Or rather, if they get it, they just don't care.
For once (Score:5, Insightful)
Re:great... (Score:2, Insightful)
Comment removed (Score:1, Insightful)
Re:For once (Score:3, Insightful)
Most flaws in any code are caused by poor programmers. It's possible to write clearly structured, well laid out code in BASIC (no, not visual BASIC, the real thing), as most implementations support things like local variables and procedures. It's just exceptionally rare.
This is why so many computer science degrees (at least until recently in the UK) used Modula-2 or Pascal as their primary teaching language. Don't for one moment imagine the lecturers thought that these languages would be useful in the real world - the idea was to teach good practise.
Re:So, PHP means ? (Score:2, Insightful)
Re:great... (Score:3, Insightful)
I'm sure that after the dust has settled PHP will be more secure than it was, and that can only be a good thing.
Re:Your site is likely already compromised. (Score:1, Insightful)
Re:even if... (Score:3, Insightful)
Re:So, PHP means ? (Score:5, Insightful)
And if inexperienced scripters is really the major problem, then the PHP developers need to take them into account when developing PHP. This means that the PHP developers need to add features to their product that help prevent such inexperienced people from writing easily-exploitable scripts. There has been some work done in this area, but it's been minimal, and so far ineffective.
Yes, inexperienced developers probably are responsible for many of the problems. But the more experienced (I would hope) developers of PHP itself need to step up to the plate, and do their part to deal with the problem of inexperienced developers writing poor code. Even if they don't do it in order to offer a better product, they should do it to save the few remaining strands of their reputation.
Re:even if... (Score:5, Insightful)
Re:great... (Score:3, Insightful)
Re:PHP is a disgrace to the open source community. (Score:4, Insightful)
One of the problems with PHP is the fact that when the bar of entry is so low, you get a lot more low bar people actually coding it. It's become the next generation of VB garbage. The language is only half of the security problem (a half we could better do without, but still).
Hear, hear. (Score:4, Insightful)
Re:Are bugs the problem? (Score:3, Insightful)
Or even more likely, how easy it is to download and run insecure code written by some other lousy programmer. It's not the people who are writing their own CMS systems that are getting haxor'd, it's the people who grabbed a copy of PHPNuke and threw it up there on the 'net.
Re:PHP needs to be fixed in general (Score:3, Insightful)
Err... he has [hardened-php.org].
Sometimes I think people don't read the articles.
Then I remember I'm reading slashdot.
Re:For once (Score:3, Insightful)
Personally I have always thought PHP to be a steaming pile of poorly thought out garbage but there is no denying its popularity despite its flaws.
A critical thinker will look at those two clauses and derive some wisdom. PHP is not "poorly thought out", it changes to meet the market's needs. Java was very well thought out, but it's mostly popular with big shops where you can hire a guy for $70,000/year to maintain a tiny little bit of a larger program. PHP is very popular because it allows a single person (or a small group) to make functional applications quickly and easily, with a lot of flexibility.
Re:great... (Score:3, Insightful)
In the case of SQL injection attacks, definitely yes. They provide add_slashes(), oh, but wait, that's insecure, so they provided mysql_escape_string() instead. Oh wait, that's insecure too, so they provided mysql_real_escape_string() instead. All the while, ignoring the fact that string concatenation is prone to security problems by its very nature, and ignoring the real solution — bound parameters — for years.
Take down the service? (Score:3, Insightful)
Really? Leaving aside the matter of using shared libraries, whenever I've had to add features to PHP it's gone like this:
The only actual downtime occurs during step 5, which lasts maybe a second at most. This is Linux after all -- you can run the old version while you're installing the new one.
Or am I misunderstanding your point?
Re:great... (Score:1, Insightful)
Re:Partially surprising (Score:1, Insightful)
However, to make a claim that the PHP team doesn't care about security is really incorrect, because in their latest versions, including PHP 5 and up, they have addressed the majority of complaints regarding insecure design.
Well, no. They've hit a couple of the big ones, it's true. But I get the impression that this is to avoid people nagging more than anything; they completely ignore plenty of other design flaws. The only reason you can say that "they addressed the majority of complaints" is because the few things they did manage to fix were so mind-bogglingly bad that everybody was complaining about them.
But more importantly, security is a property of their processes, not their design. Their processes are terrible. They ignore security reports. They dismiss crashing bugs as "user error". They don't have a release management system that copes with security patches. They did have, but they scrapped it because they were making too many security-only releases! Go ahead, tell me that isn't deliberately ignoring security.
But you simply cannot claim it is PHP's fault that someone has the power to run exec($_GET['shell_command']).
I'm not. It's true that there are vast numbers of these types of vulnerability, but a) that doesn't mean there aren't any with PHP itself, and b) some of them are directly caused by language/library misdesign (such as practically every SQL injection attack and most XSS vulnerabilities).