Buffer overflows. was Re: EMERGENCY: new remote root exploit in

From: Craig Spannring (ctsat_private)
Date: Fri Jul 17 1998 - 15:49:02 PDT

  • Next message: Ron Calhoun: "Fixes for security now available from Verity"

    The responses I've gotten can be grouped into the following broad
    categories-
    
       1)  Life would be good if we eliminated C and we will.
       2)  Life would be good if we eliminated C, but we can't.
       3)  C is the only language fast enough.
       3)  Eliminating buffer overflows is nice, but won't solve most of
           the problems.
       3)  You can write safe code in C using strncpy, snprintf, et al.
       4)  Only morons write code with buffer overflows
       5)  Modula-2 and Ada suck and you do you.
    
    I doubt the C will be eliminated for a long time, but we need to
    analyze the risks of using C for critical applications.
    
    It has been demonstrated by repeated assertion that C is faster.
    10,000 lemmings can't be wrong.  C doesn't provide enough information
    to the compiler for certain classes of optimizations.
    
    People that say eliminating buffer overflows won't have much benefit
    need to examine some data.  I took a look at some recent bugtraq
    messages.  Out of 19 security defects 7 of them were buffer overflows,
    6 were design or coding flaws, 1 was a tradeoff of 1 problems
    vs. another, 1 was a protocol weakness, 1 was the result of not
    checking validity of user supplied data before executing with /bin/sh
    and 3 were unknown.  (CERT advisories have _so_ much detail.)  Of the
    buffer overflows 6 gave you root privileges.  With the 6 design flaws
    only one gave you root privs.  Of the 8 problems that resulted in a
    root compromise, 6 of them were buffer overflows.
    
    Writing in a language that prevents buffer overflows won't solve all
    of the problems, in fact it won't even solve half of the problems, but
    it's a good start.
    
    I agree that if you use C you must use the functions that take a
    length parameter.  In fact the next time I'm asked to look at a major
    piece of C my first step will be grep '(strcpy)|(sprintf)|...' *.c.
    But since C doesn't pass the dimensions of arrays into functions
    you're job is a lot harder than it should be.
    
    I've repeatedly heard that in the hands of a good programmer that C is
    safe and it is only morons write code with buffer overflows.  A lot of
    people seem to think that Eric Allman is a pretty sharp programmer,
    but even he had a few overruns in sendmail.  Look around your office.
    How many of the programmers are exceptional, how many are average and
    how many are mediocre.  If even the good ones run into problems
    what hope do the average and mediocre ones have?
    
    Here's two snipets of (buggy) code, one in C and one in Java.
    Assuming both are compiled, which one could give root access and which
    one throws an exception?
    
       // Java
       do {
         buf[i] = getNextByteFromNextwork();
       while ('\n' != buf[i++]);
    
       /* C */
       do {
         buf[i] = getNextByteFromNextwork();
       while ('\n' != buf[i++]);
    
    Half of the programmers out there are below average.  Do we want them
    writing code in C?
    
    BTW- I must say I was surprised at the number of personal attacks I've
    received in regards to this message.  It seems like there are a lot of
    people that are threatened at the very idea of some language other
    than C.  As Mr. Spock would say, "Fascinating".  Comments regarding my
    parentage, education or IQ are not relevant to the discussion of
    making safe and secure server programs and will be ignored.
    
    --
    =======================================================================
     Life is short.                  | Craig Spannring
          Ski hard, Bike fast.       | ctsat_private
     --------------------------------+------------------------------------
     Any sufficiently perverted technology is indistinguishable from Perl.
    =======================================================================
    



    This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:05:54 PDT