Re: EMERGENCY: new remote root exploit in UW imapd

From: Craig Spannring (ctsat_private)
Date: Thu Jul 16 1998 - 17:35:04 PDT

  • Next message: twiztah: "SECURITY: imap-4.1.final now available"

    Anonymous writes:
     > the saved instruction pointer on the stack is
     > overwritten with a altered value that can result in the execution of
     > arbitrary machine code, due to coding errors in the IMAP server.
                                      ^^^^^^^^^^^^^
    
    Strictly speaking, this is true.  However the defect goes far deeper
    than a simple coding error.
    
    
     >
     > COMMENTARY
     >
     > 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?
    
    Sometime in the not to distant future there will be a major
    catastrophe related to insecure Internet software.  Perhaps a major
    bank will go broke, perhaps the stock market will be manipulated, I'm
    not sure about the specifics but it will happen.  There will be a
    congressional hearing and they will ask why such a dangerous language
    as C was choosen.  How will the industry answer that?
    
    Shortly after that software manufactuers will be held liable for
    security flaws if they can't show that they used safe techniques and
    safe languages.  C will not be considered safe and using it will open
    you up to serious liability.
    
    You ask, "When will we learn?  When?".  The answer is, "Soon."
    
    --
    =======================================================================
     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:40 PDT