Date: Tue, 02 Jan 2007 10:16:23 -0500
From: Dana Hudes <dhudes@...es.org>
To: bugtraq@...urityfocus.com
Subject: Re: PHP as a secure language? PHP worms? [was: Re: new linux malware]

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
>   

Powered by blists - more mailing lists