full-disclosure - ASN.1 telephony critical infrastructure warning

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: <1077569574.16828.26.camel@bravo.isode.net>
From: David.Wilson at isode.com (David Wilson)
Subject: 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