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]
Date: Mon, 27 Feb 2006 10:21:07 -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 Mon, 27 Feb 2006, Matthew Schiros wrote:
> 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.

That doesn't seem to follow, to me.  You cited the Linux as another
example of a product with flaws, so it seems that you thought of it
as being separate.  But now you argue that because I said that the
Linux community has less patience for design flaws that PHP's success
supports your point.  But while there's overlap between the community
of people driving Linux development and the community of people
driving PHP development, they are not the same community.

> 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.

You're right that we shouldn't apply a different standard, but it's
not clear to me that we are.  In Java, for example, a lot of thought
has been put into designing the language and platform so that they
lead the programmer into writing more secure code.  Frankly such
efforts are often misguided, and Ada is probably a good example of a
bad effort to use the language to save the programmer from himself.
I think Java has done a good job of guiding the programmer toward
better design, without getting in the way, too much.

I'm not saying that PHP should be banned from the internet.  But I
am saying that there are meaningful standards that other languages
can meet that PHP can't.  I also have to admit that PHP has a
design goal that Java does not, and that goal is the ability to
support very rapid development of programs to generate dynamic
web content.  Languages that support quick and dirty development
face different challenges than those designed for large, formal
projects.

I'm also saying that it's probably a mistake to point to the flaws
in these other platforms as a way to dismiss security related
criticisms of the design of PHP.  In particular, I don't think
security concerns were ever as central to the design of PHP the
way that they were for Java.  I think a lot of us in the security
community would be happier with PHP if there had been more thought
about security from the very start.  And whatever weaknesses Java
may have, it does at least show that designing in security from
the start can have a profound effect on a language.

> 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.

Yes, we should be grateful for that.  8-)  And things could be even
worse;  We should be glad that PHP doesn't include ActiveX.

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.



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ