[LINK] PHP, Perl and Python pass Homeland Security test

Rick Welykochy rick at praxis.com.au
Mon Jan 14 11:26:49 AEDT 2008


Antony Barry wrote:

> PHP, Perl and Python pass Homeland Security test
> Coverity, which creates automated source-code analysis tools, announced 
> late Monday its first list of open-source projects that have been 
> certified as free of security defects.
> 
> <http://www.zdnet.com.au/news/software/soa/PHP-Perl-and-Python-pass-Homeland-Security-test/0,130061733,339284949,00.htm> 

Therein lies a grand sense of false security:

  "The certification was created so that companies can "select these open-
   source applications with even greater confidence," Coverity said."

Erm .... yeah. So, no obvious buffer overflows were detected in PHP,
for example, by an automated software scanner. Big deal. That does not
make the software applications secure by any means.

PHP, continuing the example, is one of the Internet's most commonly
used languages for (often quick and dirty) websites. And it is one of
the Internet's most insecure languages. Not because of what some
automated scanner can find in its language processor. That is the
least of our worries. It is insecure because it is difficult to
write secure applications in the language.

The same can be said for Perl and Python. Yup, great scripting tools
when you keep them away from direct access by web monkeys. Once you
start writing network-exposed applications that provide SQL services,
URL parsing and passing and/or access to web app frameworks, bingo!
A clever script kiddie can exploit SQL injection, cross-site scripting
and more to exploit your application to do anything from send spam
and distribute porn to actually shutdown the service.

A google for "<language> vulnerability" (both words required consecutively)
turned up these results:

PHP     11000 hits
Perl     5170 hits
Python   2070 hits


And some examples of what can happen with PHP:

"PHP contains code for intelligently parsing the headers of HTTP POST requests.
The code is used to differentiate between variables and files sent by the user
agent in a "multipart/form-data" request. This parser has insufficient input
checking, leading to the vulnerability. ... This vulnerability may be exploited
to compromise the web server and, under certain conditions, to gain privileged access."

  e.g. roll your HTTP request and get access to the server


"Anyone with access to websites hosted on a web server which employs the CGI
module may exploit this vulnerability to gain access to any file readable by
the user under which the webserver runs."

  e.g. read any (confidential) file on the server. nasty.


"s.masugata has reported a vulnerability in PHP, which potentially can be exploited
by malicious people to use it as an open mail relay."

  e.g. use the server to send spam. really nasty. esp. if undetected.


It would be gratifying indeed if automated software scanners could find
vulnerabilities like the above real-world examples, but I am not holding breath.

Sadly, an article like this will be read by the PHB who can then report to
his superiors that, yup, he has hired PFY to write the amazing web app they
need, and he is confident the application will be secure, since a ZDnet
article says so.

The article implies that applications written in these certified languages
are secure, which is of course balderdash. The language parser and dispatcher
themselves itself may be written in a secure manner, but the same cannot be said
for applications you or I or anyone writes.

cheers
rickw





-- 
_________________________________
Rick Welykochy || Praxis Services

Say what you will about the miracle of unquestioning faith, I consider 
a capacity for it terrifying and absolutely vile.
     -- Howard W Campbell in Kurt Vonnegut Jr's "Mother Night"



More information about the Link mailing list