We all know that, due to the poor design of the language, security and PHP applications don't mix well, because PHP makes writing secure code difficult; apparently security doesn't mix well either with the mindset of the PHP core developers.
I have to admit that I'm very curious as to the backstory here. I hope that it's not a simple matter of core PHP people just not being overly concerned about security. It could be something akin to the MS situation where MS is in the terrible position of having to ensure that patches work on hundreds, if not thousands, of configurations (different hardware, different OSs, different patch levels, different software installed, etc.) Somehow, though, I suspect the worst
Re:Uh Oh
rafael on 2006-12-11T12:47:21
Reading more articles in this blog reveals what the main concern of the author -- that the PHP community tends to blame applications written in PHP for the poor security, but usually rejects critics on the language and its implementation.As somebody having some experience of language design, I can see three kinds of problems. The first one, also the simplest, is applications written with no clue about security. For example, a web form to send email, where the recipient is coded into an hidden input field -- you could use it to spam people. (Hi, Matt's script archive.)
Secondly, bugs with the implementation of the language. For example, buffer overflows in the interpreter, etc. leading to actions not intended by the language. Apparently, due to social tensions between the PHP and the hardened-PHP projects, those bugs might remain unfixed for months, or bug reports ignored by the PHP team, although they're affected. Actually that's what the blog guy asserts.
Third, security features in the design of the language itself. A recent example with perl is my addition of a new check: when perl is run under taint mode, printf() and sprintf() will now reject any tainted format argument. (Other vulnerabilities have been fixed in printf format strings, and patches quickly made available for vendors to apply; but those were actual bugs.) There is more in perl's security than the sole taint mode; but in general perl and perl modules avoid to make simple operations ridiculously simple for programmers, like importing values from the environment as globals, or allowing to use modules whose path is given by an URL (or worse).
So, I think I suspect the worse too...
Re:Uh Oh
chromatic on 2006-12-11T18:50:33
Don't discount personality conflicts either. As with any technical community, there are some people who don't mix very well. (You can usually remove the word "technically" from the previous sentence.)
For the ordinary PHP user this means that I will no longer hide the slow response time to security holes in my advisories. It will also mean that some of my advisories will come without patches available, because the PHP Security Response Team refused to fix them for months. It will also mean that there will be a lot more advisories about security holes in PHP.
Re:Public intormation
rafael on 2006-12-12T09:49:14
I would hope that problems with Perl would immediately be made public so we have a chance to deal with them. I think, however, that we probably have a more reponsive set of core developers who already do their business in public (i think, maybe I'm just not in the star chamberWell, besides perlbug and P5P there is no infrastructure to report security bugs... (and the last core security bug that was found was a printf format string vulnerability back in December 2005, which was promptly fixed.) There might be for some CPAN modules, but I'm not aware of that...:) Re:Public intormation
DAxelrod on 2006-12-13T01:53:37
That's a very good point. What additional infrastructure is needed?Re:Public intormation
grinder on 2006-12-15T10:10:59
None, probably. If you built it, it would gather dust.
I think the p5p mailing list is the best venue for reporting security problems. One doesn't have to be subscribed to post to it...
