Re: EMERGENCY: new remote root exploit in UW imapd

From: Alex Belits (abelitsat_private)
Date: Mon Jul 20 1998 - 20:18:03 PDT

  • Next message: Aleph One: "Summary: Secure Programming References"

    On Sat, 18 Jul 1998, Niall Smart wrote:
    
    > Date: Sat, 18 Jul 1998 00:51:55 +0000
    > From: Niall Smart <rotelat_private>
    > To: BUGTRAQat_private
    > Subject: Re: EMERGENCY: new remote root exploit in UW imapd
    >
    > > > In some ways, it is depressing to find this new hole.  Programmers are
    > > > still making the same mistakes they have made for years.  Doesn't anyone
    > > > learn from the past?  Can strcpy() ever be used safely?  Perhaps the
    > > > software development community, and certainly those writing network service
    > > > daemons that run as root, should discontinue using *any* C library
    > > > functions that do not include bounds checking information, such as
    > > > sprintf(), strcat(), and strcpy().  Yes, they *can* be used safely but the
    > > > potential for misuse is too great.  When will we learn?  When?
    > >
    > > C should not be used for trusted programs.  The lack of true arrays
    > > with array bounds checking alone makes it too hazardous.  How many
    > > buffer overflow attacks would we hear about if the trusted server
    > > programs were written using a language with bounds checking like
    > > Modula-2 or Ada?  Zero.
    > >
    > > The Internet is becoming a critical part of society.  Can we afford to
    > > rely on an inherently dangerous programing language?
    >
    > We can't afford to start making incorrect attributions as to the
    > cause of our security problems, thats for sure.
    >
    > C is not an inherantly dangerous programming language.  The
    > specification of the language has absolutely nothing to say about
    > how it is executed; it is possible to write a C compiler which
    > generates bounds checking code which is as effective as any produced
    > by a Modula or Ada compiler.  See, for example,
    > http://fox.doc.ic.ac.uk/~phjk/BoundsChecking.html.  Also see "Safer
    > C: Developing Software for High-Integrity and Safety-Critical
    > Systems, Les Hatton" for an interesting discussion of why the
    > vilification of C doesn't really make sense.
    
      I use strcpy() in a lot of code, and none of it had buffer overflows
    because buffers were properly allocated. OTOH, I had a horrible buffer
    overflow in a code that handled pointers by itself, and no sane bounds
    checker will notice it in that place unless it will have extremely high
    overhead.
    
      As for other languages, who said that their implementations are safe? I
    have never seen a Java VM that didn't crash on some kind of memory/pointer
    manipulation bug.
    
      Really there are two problems:
    
       1. Programmers aren't good enough, so they write crappy code.
       2. Programmers are always in a hurry, so they write crappy code.
    
      Even though string manipulation libraries may help (at least they do in
    C++ sometimes) tools and languages are pretty much irrelevant to both
    above mentioned things.
    
    --
    Alex
    



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