Re: [SC-L] The Specifications of the Thing

[Steven M. Christey]

On Tue, 12 Jun 2007, Michael S Hines wrote:

> So - aren't a lot of the Internet security issues errors or omissions in the
> IETF standards - leaving things unspecified which get implemented in
> different ways - some of which can be exploited due to implementation flaws
> (due to specification flaws)?

This happens a lot in interpretation conflicts [1] that occur in
"intermediaries" - proxies, IDses, firewalls, etc. - where they have to
interpret traffic/data according to how the end system is expected to
treat that data.  Incomplete specifications, or those that leave details
for an implementation, will often result in end systems that have
different behaviors based on the same input data.  nmap's OS detection
capability is an obvious example; Ptacek/Newsham's classic IDS evasion
paper is another.

Many of the anti-virus or spam bypass vulns being reported are of this
flavor (although lately, researchers have realized that they don't always
have to bother with interpretation conflicts when the products have
obvious overflows).

Non-standard implementations make the problem even worse, because then
they're not even acting like they're expected to, as we often see in
esoteric XSS variants.

- Steve

[1] "interpretation conflict" is my current term for
http://cwe.mitre.org/data/definitions/436.html
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___

[SC-L] The Specifications of the Thing

[Michael S Hines]

So - aren't a lot of the Internet security issues errors or omissions in the
IETF standards - leaving things unspecified which get implemented in
different ways - some of which can be exploited due to implementation flaws
(due to specification flaws)?

Mike H.
-
Michael S Hines
[EMAIL PROTECTED]


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Crispin Cowan
Sent: Monday, June 11, 2007 5:50 PM
To: Gary McGraw
Cc: SC-L@securecoding.org; Blue Boar
Subject: Re: [SC-L] Harvard vs. von Neumann

Gary McGraw wrote:
> Though I don't quite understand computer science theory in the same way
that Crispin does, I do think it is worth pointing out that there are two
major kinds of security defects in software: bugs at the implementation
level, and flaws at the design/spec level.  I think Crispin is driving at
that point.
>
Kind of. I'm saying that "specification" and "implementation" are relative
to each other: at one level, a spec can say "put an iterative loop here" and
implementation of a bunch of x86 instructions. At another level,
specification says "initialize this array" and the implementation says "for
(i=0; i If we assumed perfection at the implementation level (through better
languages, say), then we would end up solving roughly 50% of the software
security problem.
>
The 50% being rather squishy, but yes this is true. Its only vaguely what I
was talking about, really, but it is true.

Crispin

--
Crispin Cowan, Ph.D.   http://crispincowan.com/~crispin/
Director of Software Engineering   http://novell.com
AppArmor Chat: irc.oftc.net/#apparmor

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org List information,
subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___