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
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.

Reply via email to