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

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]

Message-ID: <4C12C33FB9D17644817F45CDE19662741BA55B@arthurdent.home.jalojash.org>
Date: Tue, 2 Jan 2007 11:18:55 -0800
From: "Jim Harrison" <Jim@...tools.org>
To: <bugtraq@...urityfocus.com>
Subject: RE: PHP as a secure language? PHP worms? [was: Re: new linux malware]

"..comment has nothing to do with either.." - I'm addressing the
generalistic "genuine security" arguments offered in this discussion.  I
have no contrary argument to the point that PHP in its current
incarnation is not designed to be secure; only that those who espouse
the idyllic language are in for a nasty surprise (if they're paying
attention at all).

"..you're saying "genuine security" is impossible.." - yes; that's
exactly what I'm saying.
I'm not trying to use it as a dissuading argument, only a reality check.

-----Original Message-----
From: Darren Reed [mailto:avalon@...igula.anu.edu.au] 
Sent: Tuesday, January 02, 2007 10:37 AM
To: Jim Harrison
Cc: bugtraq@...urityfocus.com
Subject: Re: PHP as a secure language? PHP worms? [was: Re: new linux
malware]

In some mail from Jim Harrison, sie said:
> 
> 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.

This discussion is about secure programming and the problems related to
PHP.  Your comment has nothing to do with either except to state that
what is considered secure by two different environments are actually
different (big deal.)

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

Well given that the ultimate root of any invention is going to be human,
you're saying "genuine security" is 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.

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

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.  Just as people using
perl generally don't need to worry about buffer overflows, why should
people using PHP need to worry about SQL escapes and filepath issues?
They shouldn't.

Darren

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