[Dailydave] Boom! Loopcasts.
security curmudgeon
jericho at attrition.org
Tue Aug 20 15:18:27 EDT 2013
On Tue, 20 Aug 2013, Justin C. Klein Keane wrote:
: I think it's irresponsible to label an entire language insecure, even
: one like PHP, which is the favorite whipping boy of the security
: community. While it is accurate to say that PHP is an extremely
: widespread, and easy to learn, programming language for producing
: globally available always-on web applications, and that the popularity
: and ease of PHP lend themselves to novice's producing insecure
: applications in the language, it is not accurate to say that PHP itself
: is insecure. PHP based applications suffer just as many security flaws
: as any other application. Security, or lack thereof, is derived in
: implementation.
:
: While we can make specific claims about security related attributes of
: PHP, such as: PHP doesn't allow the programmer to make unchecked memory
: assignments (i.e. no buffer overflows), we can't say that this makes the
: language secure or insecure. It is just as easy to produce an insecure
: web application in Java, or ASP.NET, [4] as it is in PHP. Singling out
: an entire language for derision doesn't really advance any conversation
: of purpose.
If you look purely at vulnerabilities, as documented by vulnerability
databases, that affect the language itself, as opposed to the applications
written in them, then Dave's comment holds up.
- There are over 600 documented vulnerabilities in PHP itself.
- There are over 150 documented vulnerabilities in Ruby, but some of those
are third-party gems.
- There are over 40 documented vulnerabilities in GNU C Library (glibc).
Perl and Python are a bit trickier to quickly determine for me (like you,
not spending much time on this).
Just based on that alone, PHP has obvious deficiencies. Then throw in the
poor coding practices of PHP developers and it's a mess. I am not going to
speak to Ruby because it is a relatively new language compared to the
others, and with the eleventy-billion gems, it is just begging to get bent
over. We've recently seen a single researcher (Larry Cashdollar) show that
Ruby gems frequently have trivial old-school vulnerabilities in them,
demonstrating that even the newer languages haven't accounted for an
entire classes of old vulnerabilities.
: posture. If Immunity had a PHP based web forum compromise, and didn't
: review the forum software before deploying it, the fault doesn't lie in
: PHP, but with Immunity for not performing due diligence with respect to
: the software.
By that logic, then it is never the fault of the software, always the
fault of the organization.
Are you really suggesting we thrust that responsibility entirely on the
end user?
More information about the Dailydave
mailing list