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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1077569574.16828.26.camel@bravo.isode.net>
Date: Mon, 23 Feb 2004 20:52:54 +0000
From: David Wilson <David.Wilson@...de.com>
To: Zak Dechovich <ZakGroups@...UREOL.COM>
Cc: bugtraq@...urityfocus.com, full-disclosure@...ts.netsys.com
Subject: RE: [Full-Disclosure] ASN.1 telephony critical infrastructure
	warning - VOIP


On Tue, 2004-02-17 at 16:31, Zak Dechovich wrote:
> I would like to answer you all together, as I was the one who started this
> thread,
> 
> ASN1 is a simple data encapsulation, the problem occurs when the
> decapsulation procedure fails because of any reason.
> in the case at hand, the data slips into the code segment.

ASN.1 = Abstract Syntax Notation number One.

As part of the definitions, there are also defined encoding rules, for
the interchange of values defined using ASN.1. The most common rules are
BER (Basic Encoding Rules).

It should be emphasised that ASN.1 and BER are NOT vulnerable, at least
any more than IP packet encodings, or TCP packet encodings are
vulnerable.

What are potentially vulnerable are _implementations_ of
encoders/decoders which take convert between the on-the-wire encoding
(e.g. BER) and some internal alternative concrete representation of the
abstract values. The recent well-publicised vulnerability in Microsoft's
BER decoding library is an example of such a problem with an
_implementation_.

There is actually little excuse for this kind of thing. The University
of Oulu produced their first test suites some time ago, and I see they
have quite a range now: 

<URL:http://www.ee.oulu.fi/research/ouspg/protos/>.

which seems to include telephony protocols.

Then there have been test suites based on these for S/MIME, X.400
P22/P772 and (certificates in) SSL.

There is actually little excuse for any software producer who has code
which uses ASN.1 for having an implementation which does not pass these
kinds of test. Even if there is not a test suite available from someone
else, such as Oulu, then the basic principles of the test are very
simple, and tests can be generated fairly mechanically.

You are right in saying there _may_ be vulnerabilities via any protocol
which uses ASN.1, but only if the _implementation_ is at fault. In the
case of such implementations running on Microsoft Windows, that may
depend on the implementation they are using (Microsoft or some other).

cheers

-- 
David Wilson <David.Wilson@...de.com>
Isode Limited



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ