[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <459AA90E.3080705@ornl.gov>
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