Date: Tue, 02 Jan 2007 13:48:46 -0500
From: Lawrence Paul MacIntyre <macintyrelp@...l.gov>
To: Dana Hudes <dhudes@...es.org>
Cc: bugtraq@...urityfocus.com
Subject: Re: PHP as a secure language? PHP worms? [was: Re: new linux malware]

Dana:

The "S" in RSA stands for Adi Shamir, not Ravi Sethi.  Ravi is the 
author of the "Dragon Book", however.

This one time, at band camp, Dana Hudes wrote:
> Darren Reed wrote:
>
>> In functional programming languages (think 4GLs like prolog),
> Prolog isn't a 4GL (it was invented in 1972 ).  In Ravi Sethi's  
> _Programming Languages: Concepts and Paradigms_ (2nd ed1996) he 
> defines some of the paradigms of programming languages; on pp 12-13, 
> he provides a family tree.  This book is classic (for those who don't 
> know this is the 'S' in RSA,  co-author of the famous 'Dragon Book' on 
> compiler design etc.) but doesn't list Perl or PHP or Java -- but the 
> concepts are the same.  I'm summarizing various pieces of the book's 
> summary here and only listing the noteworthy parts:
>
> In brief you have 3 basic paradigms (more could be invented later; PHP 
> and Perl aren't inventing new paradigms):
> *Imperative - these are the descendants of FORTRAN and ALGOL: Pascal 
> (and its descendants Modula-2 and Ada), C, C++, Java, etc.
> *Functional e.g. LISP and its descendants ML, Scheme, and Haskell (a 
> descendant of ML and Scheme).
> *Logic e.g. Prolog
>
> Object-Oriented is an extension found in imperative (C++, Java, 
> etc.)and somewhat in functional (viz., CLOS); it has its origins in 
> Simula and Smalltalk.
>>  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.
>>
>>   
> Building PHP on top of BLISS or assembler wouldn't help.  C has its 
> place as a "portable assembler".  As has been noted, there aren't so 
> many vulnerabilities in the PHP language parser. Design defects that 
> encourage poor programming practices, sure. But you can write 
> bulletproof PHP. Also note that "externally supplied input" is a broad 
> range of things. As I originally stated in my previous post, use of 
> type-safe languages goes a long way toward fixing these things but 
> isn't a cure all (as you mention shell escapes and the like). Buffer 
> overflows, now that's a defect in the design of the runtime library 
> and perhaps the language. It simply should not be possible to overrun 
> a buffer. Either the language auto-extends the buffer (Perl) or it 
> should fail the operation if not abort the program. Yes, in C you can 
> blithely write past the end of an  array and thereby smack the stack. 
> You're supposed to do the work of bounds checking in your code so that 
> in the cases where you KNOW that the input fits in the array (e.g. 
> initializing an array from a constant; esp. when you malloc 
> (strlen("foo")) you don't incur the bounds checking overhead on 
> assignment. If you don't put in bounds checking where its needed 
> that's your bug not the compiler's.
>
> SQL injection attacks don't attack PHP. They don't even crash your PHP 
> program. They attack the dbms and your application system (or 
> 'stack'). I don't believe I've seen any SQL injection attacks gain 
> system privileges (only idiots run the dbms as root; I have some of 
> those at work and they are fighting with me to thwart my knocking them 
> out of root...come  Solaris 10 deployed in our production, I won't 
> care I'll lock them in a container they will see nothing they're not 
> supposed to and have access only to their own stuff not the system and 
> finally the DBAs will stop crying that they want to run top all the 
> time -- and if they DO run top they'll only see their own stuff...they 
> aren't getting anywhere near the global zone). Rather they do 
> something nasty to steal your data (e.g., username/passwords, credit 
> card info and so on) or to put their own stuff in (html to load a 
> virus or trojan horse etc.).
>
> When you look at vulnerabilities you have to also look at the impact. 
> Remote privilege escalation is different from having your data stolen.
>
>
>
>
>
>> So maybe there isn't a "secure" functional language yet but I can't
>> see why we can't develop one.
>>   
> You keep misusing functional when you mean imperative. Have you seen 
> any mention of vulnerabilities in LISP/ML/Scheme/Haskell recently? 
> Mind you Scheme is all over the place because of Gnome project.
> Have you read _Building Secure Software_ by Viega and McGraw? Have you 
> looked at switching to ML?
>> Darren
>>   
>


-- 
  Lawrence MacIntyre   865.574.8696   macintyrelp@...l.gov
                Oak Ridge National Laboratory
Cyber Security and Information Infrastructure Research Group

Protect your digital freedom and privacy, eliminate DRM.
Learn more at http://www.defectivebydesign.org/what_is_drm

Powered by blists - more mailing lists