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

["Jim Harrison" <Jim () isatools org>]

No; this wasn't flame-bait, although I'd be silly not to expect some.
Let me make my position clear; the goals of secure coding and secure
languages are both grand and well worth the time spent.

There are two primary factors which make this an impossible task:

1. "secure" is moving, contextual target.  That which is deemed "secure"
by today's standards will be "just ok" or "watta joke" by future
evaluators.  What is good enough for Joe's Garage won't even make it in
the door of Fred's Bank (3 anti-social points for each reference),
although some could argue that Joe's security requirements should equal
Fred's, since they both pin their business on it. 

2. Until the human factor is removed from both, mistakes and simple
ignorance will always render them both "less than secure" in any
context.  This is the core of my argument.

Again; I agree with and fully support the effort.  What I'm trying to
point out is the literal impossibility of actually achieving "genuine
security" in either our code or the languages it's written in.

-----Original Message-----
From: Darren Reed [mailto:avalon () caligula anu edu au] 
Sent: Tuesday, January 02, 2007 2:58 AM
To: Jim Harrison
Cc: Dana Hudes; bugtraq () securityfocus com
Subject: Re: PHP as a secure language? PHP worms? [was: Re: new linux
malware]

In some mail from Jim Harrison, sie said:
> ..and similar statements can be made for Basic (pickyourflavor) as
well.
> This argument proves my point that there is no such thing as a truly 
> "secure" language; it's entirely dependent on the dev skills.

I disagree.  But then the above could be taken to be just flame-bait.

In functional programming languages (think 4GLs like prolog), rather
than functional programming languages (2 and 3GL - C/Pascal/perl/etc),
the ability of a programmer to do something that exposes a security
problem is greatly diminished (if we exclude "shell escapes", etc.)

Where do 9 out of 10 security problems with applications arise from?

Dealing poorly with externally supplied input.

This is the crux of nearly *all* PHP security bugs.

Maybe our problem is that PHP, perl, etc, are all built on top of C and
in such a manner that the origin and trustworthiness of data is lost and
can no longer be delt with in an appropriate fashion.

So maybe there isn't a "secure" functional language yet but I can't see
why we can't develop one.

Darren

All mail to and from this domain is GFI-scanned.