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]

Date: Wed, 3 Jan 2007 05:37:19 +1100 (Australia/ACT)
From: Darren Reed <avalon@...igula.anu.edu.au>
To: Jim@...tools.org (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