[devel] Fw: Best Anti-ASN.1 Rant Ever.

[devel] Fw: Best Anti-ASN.1 Rant Ever.

[Alexander Bokovoy]

----- Forwarded message from Jeremy Allison <jra@samba.org> -----

Date: Tue, 10 Feb 2004 16:02:13 -0800
From: Jeremy Allison 

>From slashdot no less :-).

-----------------------------------------------------

Yes. This isn't the third DIFFERENT bug in ASN.1 discovered recently -
this is the third set of applications using the SAME REFERENCE
IMPLEMENTATION of ASN.1 that was discovered to be vulnerable once it was
discovered that the reference implementation was buggy. SNMP and SSL got
hit, then just recently H.323 got hit, and I don't know what Microsoft
parts just got hit (but it wouldn't surprise me if it's Netmeeting and
maybe IE.)

Why? Because ASN.1 is the Mos Eisley of bit-twiddly protocols, and "you'll
never find a more wretched hive of scum and villainy." AFAIK, there's
nothing insecure about the protocol itself, but it's so ugly that
everybody tends to reuse the reference implementation rather than
rewriting their own. While that has some good aspects to it, some of the
original reference implementation code wasn't always careful about
checking bounds, etc., and eventually the University of Oulu folks did a
proper study and found the holes.

ASN.1 is one of these broad-scope protocols that tries to be everything to
everybody, so it not only implements in a broad messy manner some things
that were done much more simply and cleanly and debuggably in XDR, it also
does some other things that are useful in a top-down hierarchical world
controlled by all-knowing standards committees, and got itself included at
the appropriate layers in other standards such as X.509 and H.323 (which
are also big and ugly), and in SNMP (which is otherwise simple and clean
and should have known better), and X.509 got itself embedded into SSL.
(H.323 is the older VOIP standard, used by almost everybody even though
they talk about using SIP Real Soon Now, and Microsoft Netmeeting is the
popular free implementation.) One bad side of this is that very many
security-critical applications have this buggy code at the bottom of them,
though this is somewhat balanced by the good fact that it's so deeply
buried that it's often hard to pass malicious data that far down the
stack, though of course there's the ugly side which is that it's so ugly
that it's hard for an interface module to verify that an ASN.1 object is
malformed except by actually passing it to the vulnerable ASN.1
interpreter.

Bit-twiddly space-saving data formats are almost always a Bad Idea. As
they say, people who play with the bits deserve to be bitten. ASN.1
problems make many applications hard to write and harder to debug, but in
the Open Source world, PGP has gone through several iterations of
security-critical bugs because they were trying to steal bits, plus
backwards compatibility issues make stealth versions difficult. The theory
is that it's somehow more "efficient" to save a few bits of data storage
or data transmission time by using variable-length formats, trading off
the space for more CPU time and program space. This isn't totally off the
wall, given 20 years of Moore's Law (which seems to have improved CPU and
RAM price/performance by 10**5 - 10**6, disk by about 10**5, but smaller
bandwidths by only 10**3-10**4), but the cost in programmer time,
debugging time, and bug impact has been immense.
-----------------------------------------------------

Couldn't have said it better myself - especially the bit about
XDR :-).

Jeremy.

----- End forwarded message -----

-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/

[devel] Fw: Best Anti-ASN.1 Rant Ever.

[Alexander Bokovoy]

----- Forwarded message from Jeremy Allison <jra@samba.org> -----

Date: Tue, 10 Feb 2004 16:02:13 -0800
From: Jeremy Allison 

>From slashdot no less :-).

-----------------------------------------------------

Yes. This isn't the third DIFFERENT bug in ASN.1 discovered recently -
this is the third set of applications using the SAME REFERENCE
IMPLEMENTATION of ASN.1 that was discovered to be vulnerable once it was
discovered that the reference implementation was buggy. SNMP and SSL got
hit, then just recently H.323 got hit, and I don't know what Microsoft
parts just got hit (but it wouldn't surprise me if it's Netmeeting and
maybe IE.)

Why? Because ASN.1 is the Mos Eisley of bit-twiddly protocols, and "you'll
never find a more wretched hive of scum and villainy." AFAIK, there's
nothing insecure about the protocol itself, but it's so ugly that
everybody tends to reuse the reference implementation rather than
rewriting their own. While that has some good aspects to it, some of the
original reference implementation code wasn't always careful about
checking bounds, etc., and eventually the University of Oulu folks did a
proper study and found the holes.

ASN.1 is one of these broad-scope protocols that tries to be everything to
everybody, so it not only implements in a broad messy manner some things
that were done much more simply and cleanly and debuggably in XDR, it also
does some other things that are useful in a top-down hierarchical world
controlled by all-knowing standards committees, and got itself included at
the appropriate layers in other standards such as X.509 and H.323 (which
are also big and ugly), and in SNMP (which is otherwise simple and clean
and should have known better), and X.509 got itself embedded into SSL.
(H.323 is the older VOIP standard, used by almost everybody even though
they talk about using SIP Real Soon Now, and Microsoft Netmeeting is the
popular free implementation.) One bad side of this is that very many
security-critical applications have this buggy code at the bottom of them,
though this is somewhat balanced by the good fact that it's so deeply
buried that it's often hard to pass malicious data that far down the
stack, though of course there's the ugly side which is that it's so ugly
that it's hard for an interface module to verify that an ASN.1 object is
malformed except by actually passing it to the vulnerable ASN.1
interpreter.

Bit-twiddly space-saving data formats are almost always a Bad Idea. As
they say, people who play with the bits deserve to be bitten. ASN.1
problems make many applications hard to write and harder to debug, but in
the Open Source world, PGP has gone through several iterations of
security-critical bugs because they were trying to steal bits, plus
backwards compatibility issues make stealth versions difficult. The theory
is that it's somehow more "efficient" to save a few bits of data storage
or data transmission time by using variable-length formats, trading off
the space for more CPU time and program space. This isn't totally off the
wall, given 20 years of Moore's Law (which seems to have improved CPU and
RAM price/performance by 10**5 - 10**6, disk by about 10**5, but smaller
bandwidths by only 10**3-10**4), but the cost in programmer time,
debugging time, and bug impact has been immense.
-----------------------------------------------------

Couldn't have said it better myself - especially the bit about
XDR :-).

Jeremy.

----- End forwarded message -----

-- 
/ Alexander Bokovoy
Samba Team                      http://www.samba.org/
ALT Linux Team                  http://www.altlinux.org/
Midgard Project Ry              http://www.midgard-project.org/