Re: PHP as a secure language? PHP worms? [was: Re: new linux malware]

I think you're making my point for me. If, as you say, the Linux
community has a faster turn-around time on poorly designed and
supported applications than, say, the Windows community, if PHP were
actually as bad as some people try to make it out, there'd be no
market penetration for it, as it would have been abandoned in the
early days.

PHP gets a hard time because it has both kinds of flaws that you
describe: design & implementation. Design because there are
legitimate security flaws in PHP, implementation because any script
kiddie with a text editor can go out and write a BBS app, a webmail
client, etc., with little to no checking on the part of the community.
PHP, and web languages in general, rely on developer attention to
security more than they do on safeguards built into the engine.

Obviously, the flaws in PHP aren't the same as those in Java or sshd,
and I'm not saying we should simply "count flaws", although that's
something that should be done as PART of the evaluation of any
product. But we can't apply a different standard to PHP, and refuse
to recognize that the overwhelming majority of security issues raised
by PHP are implementation, not design. To be fair, PHP's drastically
improved since the 3 & 4 days, and there's a lot of understandable
angst toward it that has carried over since then, but perhaps a
factual update would be in order.

I'm not saying PHP is perfect, or that it's 100% secure, or even that
it behaves as documented all the time. But at least it's not ASP.

On 2/27/06, L. Adrian Griffis <agriffis@xxxxxxxxxxxxxx> wrote:
On Fri, 24 Feb 2006, Matthew Schiros wrote:
PHP, like any and all projects, does indeed have security flaws. So
does MySQL. So does Linux. So does sshd. So does Windows. To claim
that we should abandon any individual service simply because it has
security bugs is absurd. Yes, there are non-trivial problems with
PHP's memory management, but the same could easily be said for Java as

You may be missing an important point, here. Not all security flaws are
alike. We can divide security flaws into two catagories. Those
catagories are Design Flaws and Implementation Flaw. Implementation
flaws can lead to serious problems, but from a security perspective,
they are easier to deal with because correcting them is likely to make
the behavior of the afflicted programs more like what the users expect.
That is, assuming the documentation accurately reflects the programmer's
intentions, correcting implementation flaws should usually make the
program's behavior more consistent with the documentation.

Design flaw, on the other hand, are more serious, because correcting
those flaws can mean breaking program behaviors that the user was
told he could count on. Vendors live with their bad designs for years,
simply to avoid upsetting user expectations.

While you are correct that sshd and Java have occasional flaws with
security implications, not all security flaws are alike. sshd and
Java were more carefully designed than many other tools in this
business, and the Linux community is much quicker to abandon badly
flawed designs than some other communities. You can't make meaningful
comparisons on security by simply counting flaws.


This e-mail and any attachments are intended only for the
individual or company to which it is addressed and may contain
information which is privileged, confidential and prohibited from
disclosure or unauthorized use under applicable law. If you are
not the intended recipient of this e-mail, you are hereby notified
that any use, dissemination, or copying of this e-mail or the
information contained in this e-mail is strictly prohibited by the
sender. If you have received this transmission in error, please
return the material received to the sender and delete all copies
from your system.

Relevant Pages