Re: Secure popen

From: Glynn Clements (glynn.clementsat_private)
Date: Thu Jun 21 2001 - 08:07:40 PDT

  • Next message: John Viega: "Re: Secure popen"

    Nick Brawn wrote:
    
    > > > Is there any specific reason why you are writing a simple CGI in c++? If
    > > > it is for learning, then I can see the point but this can easily be done
    > > > securely and efficiently in PERL or perhaps PHP(never had a chance to do
    > > > this).
    > > 
    > > Whilst it's theoretically possible to write a secure CGI in Perl, it's
    > > a lot easier to get it right in a language such as C++ which:
    > > 
    > > a) doesn't make extensive use of "in-band signalling" (i.e.
    > > subsitutions triggered by metacharacters),
    > > 
    > > b) has (reasonably) strong typing, and
    > > 
    > > c) tends to be legible.
    > > 
    > > Scripting languages such as Perl are useful for quick hacks, but
    > > security-wise, they truly suck. Scan the BugTraq archives for
    > > references to CGI programs; I would guess that around 90% of
    > > vulnerabilities are due to the above.
    > 
    > Is the reason for the large number of vulnerabilities in perl-based
    > CGI's due to the language? This is what you appear to be saying.
    
    That is basically what I'm saying. It applies to scripting languages
    generally, but Perl is arguably an extreme case.
    
    > My thought is that because perl is easier for entry-level programmers 
    > to program in, those programmers will use it for developing web and other 
    > applications. 
    > 
    > Less-experienced programmers generally make more mistakes (or poor 
    > design choices) than more-experienced programmers.
    
    That's an issue, but I don't think that it's the only issue. In many
    respects, BASIC would be less problematic than Unix-style scripting
    languages, as it doesn't generally use textual substitution in the way
    that scripting languages do.
    
    Ultimately I think that scripting languages encourage the construction
    of programs which are "99% correct", i.e. they work fine unless their
    input contains unexpected characters (e.g. language metacharacters).
    
    This thread started with a question about a "secure" popen() function.
    What's insecure about popen() itself is the fact that it passes its
    input to a script interpreter (/bin/sh).
    
    The real issue is a) above. Scripting languages, by their nature, make
    heavy use of "in-band signalling", where language constructs are
    embedded within data. Unless care is taken to prevent the problem, the
    risk is that user-supplied "data" can effectively become user-supplied
    code.
    
    Note that similar issues do occasionally occur with C; most notably
    regarding printf() format strings (which have also become a recurring
    theme on BugTraq). However, here the problem is with a few specific
    functions. With scripting languages, it's at the core of the language.
    
    -- 
    Glynn Clements <glynn.clementsat_private>
    



    This archive was generated by hypermail 2b30 : Thu Jun 21 2001 - 08:34:10 PDT