Re: SECURITY.NNOV: The Bat! <cr> bug

From: William D. Colburn (aka Schlake) (wcolburnat_private)
Date: Mon Apr 23 2001 - 22:19:46 PDT

  • Next message: Donaldson, Matthew: "Re: Linux patches to solve /tmp race problem"

    On Mon, Apr 23, 2001 at 02:38:16PM -0600, Chris Thompson wrote:
    > Programs should not crash or allow security violations when presented with
    > unexpected input.  So while the SMTP servers probably shouldn't be passing
    > along these messages, nor should the email clients be crashing.
    
    I like what RFC1123, Requirements for Internet Hosts -- Application and
    Support, by R. Braden, Editor, October 1989, has to say about this:
    
          1.2.2  Robustness Principle
    
             At every layer of the protocols, there is a general rule whose
             application can lead to enormous benefits in robustness and
             interoperability:
    
                    "Be liberal in what you accept, and
                     conservative in what you send"
    
             Software should be written to deal with every conceivable
             error, no matter how unlikely; sooner or later a packet will
             come in with that particular combination of errors and
             attributes, and unless the software is prepared, chaos can
             ensue.  In general, it is best to assume that the network is
             filled with malevolent entities that will send in packets
             designed to have the worst possible effect.  This assumption
             will lead to suitable protective design, although the most
             serious problems in the Internet have been caused by
             unenvisaged mechanisms triggered by low-probability events;
             mere human malice would never have taken so devious a course!
             protocol specification that contains an enumeration of values
             for a particular header field -- e.g., a type field, a port
             number, or an error code; this enumeration must be assumed to
             be incomplete.  Thus, if a protocol specification defines four
             possible error codes, the software must not break when a fifth
             code shows up.  An undefined code might be logged (see below),
             but it must not cause a failure.
    
             The second part of the principle is almost as important:
             software on other hosts may contain deficiencies that make it
             unwise to exploit legal but obscure protocol features.  It is
             unwise to stray far from the obvious and simple, lest untoward
             effects result elsewhere.  A corollary of this is "watch out
             for misbehaving hosts"; host software should be prepared, not
             just to survive other misbehaving hosts, but also to cooperate
             to limit the amount of disruption such hosts can cause to the
             shared communication facility.
    
    --
    William Colburn, "Sysprog" <wcolburnat_private>
    Computer Center, New Mexico Institute of Mining and Technology
    http://www.nmt.edu/tcc/     http://www.nmt.edu/~wcolburn
    



    This archive was generated by hypermail 2b30 : Tue Apr 24 2001 - 23:55:13 PDT