Message-id: <5AAB65CE-BEC6-410D-A72A-ACAAFB2496A7@opus1.com>
Date: Tue, 02 Jan 2007 21:16:12 -0800
From: Ronald Chmara <ron@...s1.COM>
To: Darren Reed <avalon@...igula.anu.edu.au>
Cc: Jim@...tools.org (Jim Harrison), bugtraq@...urityfocus.com
Subject: Re: PHP as a secure language? PHP worms? [was: Re: new linux malware]

On Jan 2, 2007, at 10:37 AM, Darren Reed wrote:
> In some mail from Jim Harrison, sie said:
>> 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.
> Well given that the ultimate root of any invention is going to be
> human, you're saying "genuine security" is impossible.

"Genuine Security" is a marketing term (a misleading one, at that). A  
programming language without security risks is pretty much useless. A  
capable web programming language without security risks is darned  
near impossible.

> I'm quite confident that someone could develop a very secure
> interpreted language.  It might not do a lot, but it could easily
> be done (even if only to prove you wrong) - if one doesn't already
> exist.  I could probably even prove a case with /bin/sh.

Sorry, /bin/sh needs read access to /etc/passwd for uname checks, and  
thus, allows for information disclosure.

Hm.

LOGO is pretty safe to use. I'm not sure how much you can do with it  
anymore. You might be able to draw web pages.... really.... slowly.....

> The problem we have right now is that the language commonly used for
> dynamic web pages on non-Microsoft platforms is PHP and that this has
> not been engineered *for security*.

PHP was engineered with the power (and responsibilities) of C. It  
allows for on-the-fly database administration, file access at the  
level of permission given to the web server process, and input/output  
at the level of raw data streams.

PHP is not a web "scripting" language, so much as a scripting  
interface to raw binary libraries on the disk, and raw machine  
resources. Thus, if an admin wants to build a PHP program to  
administer a massive DB cluster at the CLUI level, they can. If they  
want to run the world's largest online encyclopedia, they can.

They can also write an address book.

> The goal of a language such as PHP should be to make it possible
> to do what is required without the person using it needing to know
> anything about security or secure programming practices.

I think you might be a tad confused about the goals of PHP, or hoping  
that their goals match yours.

"PHP, which stands for "PHP: Hypertext Preprocessor" is a widely-used  
Open Source general-purpose scripting language that is especially  
suited for Web development and can be embedded into HTML. Its syntax  
draws upon C, Java, and Perl, and is easy to learn. The main goal of  
the language is to allow web developers to write dynamically  
generated webpages quickly, but you can do much more with PHP."

Note: "web developers", not "bored college students who tend to put  
SQL arguments into a GET string" or "oops, I didn't bother to check  
my args because the bong distracted me".

Just because it's easy to learn how to use a gun does *not* give  
people license to shoot themselves in the foot and then complain that  
the gun was "too easy to use".

> Just as
> people using perl generally don't need to worry about buffer
> overflows,

Er, what? As soon as a perl user "glues" into an external library,  
they better start to worry about such things, or expect to get a pink  
slip.

> why should people using PHP need to worry about SQL
> escapes and filepath issues?

Let us entertain your idea.

Let us imagine a language that is near useless for database  
administration, because all of the "dangerous" statements to drop  
tables, or bulk update data, are removed.
Let us imagine a language where every "dangerous" file path is  
removed, and thus, renders the language useless for any operation  
that traverses a file path.
Let us imagine a language that only allows for limited looping, so it  
cannot suck too much CPU.
Let us imagine a language where all data is "auto-sanitized", so it  
cannot handle complex binary streams.

PHP is *not*, and *never has been*, this language.

Perhaps, though, there is such a need for such a language that it can  
be developed...

...but I wouldn't use it, and neither would most of the people who  
need powerful code tools. I suggest you study the last 10 years of  
"web languages", it's a veritable highway of death of similar  
intentions, and dead-ends.

-Bop

Powered by blists - more mailing lists