Re: [Full-disclosure] On Interpretation Conflict Vulnerabilities
* 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.