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