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@xxxxxxxxxxxxxxxxxxx] Sent: Tuesday, January 02, 2007 2:58 AM To: Jim Harrison Cc: Dana Hudes; bugtraq@xxxxxxxxxxxxxxxxx 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.
