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

["Matthew Schiros" <schiros () gmail com>]

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 () dstsystems com> 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
> > well.
>
> 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.
>
> Adrian
>
>
> -----------------------------------------
> 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.