bugtraq - RE: OBJECT Bugs or Features

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date: Wed, 9 Jun 2004 10:37:52 -0700
From: Michael Wojcik <Michael.Wojcik@...rofocus.com>
To: bugtraq@...urityfocus.com
Cc: nick@...us-l.demon.co.uk
Subject: RE: OBJECT Bugs or Features

> From: Nick FitzGerald [mailto:nick@...us-l.demon.co.uk] 
> Sent: Wednesday, June 09, 2004 8:24 AM
> 
> Especially in the case of RFC'ed protocols, because of the 
> aforementioned "be lenient in what you accept" directive ... the 
> historical standard has been "accept it and do your best", leasing to 
> all manner of "compliant but utterly incompatible" shite being foisted 
> on the world _AND_ boatloads of otherwise really easily avoided dire 
> security vulnerabilities.

What Nick's referring to here is half of the "Robustness Principle",
presented by Jon Postel in RFC 793 (STD 7, Transmission Control Protocol):

  TCP implementations will follow a general principle of robustness:
  be conservative in what you do, be liberal in what you accept from
  others. (2.10)

Unfortunately Postel did not qualify this rule beyond labelling it
"general", or indeed provide any discussion of it at all.  (Ironically, it
immediately follows the brief discussion of TCP security in the RFC.)  I
tend to agree with Nick that it has been applied over-broadly.  Subsequent
RFCs, such as 1123 (Host Requirements), latched onto it eagerly and
uncritically (1123 presents it as applying "at every layer of the protocols"
(1.2.2)), even when - as in 1123 - they go on to tout it as a security
measure!

Of course, the Robustness Principle, suitably interpreted, can produce more
secure software.  As the discussion in 1123 suggests, all software should be
written under the assumption that it can receive *any* input, and it should
react accordingly.  The problem is more in determining what an appropriate
response should be.  Too often the RP is understood by developers to
indicate that the best course is for the application to attempt to
compensate for deviations from the protocol and stagger on ahead with its
best guess as to the sender's (and user's) desires.  This is not the route
to secure software.

One effect of this common misinterpretation is to site the RP as "be
conservative in what you produce, be liberal in what you accept".
Substituting "produce" for "do" in the "conservative" clause of Postel's
original formulation is a gross error - it restricts what aspects of the
implementation are constrained to be conservative, and suggests that care is
only necessary when considering the implementation's output, and not its
internal behavior.

We've had discussions of the RP in various forums before, of course.  I
believe I made a point similar to Nick's in a posting to Vuln-Dev some time
ago, but the topic is still vital, as many developers take the RP (often in
its misquoted form) as gospel.

-- 
Michael Wojcik
Principal Software Systems Developer, Micro Focus