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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.61.0602270916050.7303@dt26453.dstsystems.com>
Date: Mon, 27 Feb 2006 09:26:51 -0600 (CST)
From: "L. Adrian Griffis" <agriffis@...systems.com>
To: Matthew Schiros <schiros@...il.com>
Cc: Kevin Waterson <kevin@...ania.net>, bugtraq@...urityfocus.com
Subject: Re: PHP as a secure language? PHP worms? [was: Re: new linux malware]

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.