Full Disclosure mailing list archives
Re: On Interpretation Conflict Vulnerabilities
From: Florian Weimer <fw () deneb enyo de>
Date: Thu, 03 Nov 2005 22:37:17 +0100
* Steven M. Christey:
This falls under a class of vulnerabilities that I refer to as either "interpretation conflicts" or "multiple interpretation errors" depending on what time it is, though I'm leaning toward interpretation conflicts.
I agree that this class of vulnerabilities deserves its own name.
These types of problems frequently occur with products that serve as intermediaries, proxies, or monitors between other entities - such as antivirus products, web proxies, sniffers, IDSes, etc.
To some extent, it's a layering violation (or the lack thereof): For some reason, you implement a security check at a different layer (or in a different component) from where it is actually needed. It can also happen within the same product. For example, in a word process with macro capabilities, you add code to check for macros when an untrusted document is opened, but this code fails to detect the presence of all macros (in contrast to the macro execution engine, which is invoked later and happily executes all of them).
However, if the end products already exhibit unexpected behaviors, the reality is that intermediaries are forced into anticipating all possible interpretation conflicts, and blamed if they do not.
In the end, there is no real replacement for non-vulnerable software, no matter how many proxies and filters you put in front of it. _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Current thread:
- On Interpretation Conflict Vulnerabilities Steven M. Christey (Nov 01)
- Re: On Interpretation Conflict Vulnerabilities Florian Weimer (Nov 03)