lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <871x1xct0y.fsf@mid.deneb.enyo.de>
Date: Thu, 03 Nov 2005 22:37:17 +0100
From: Florian Weimer <fw@...eb.enyo.de>
To: "Steven M. Christey" <coley@...re.org>
Cc: full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com
Subject: Re: 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.
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ