[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <459A7747.1090202@hudes.org>
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