From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Wed, 11 Feb 2004 12:08:01 +0200 From: Alexander Bokovoy To: devel@altlinux.ru Message-ID: <20040211100801.GC5086@sam-solutions.net> Mail-Followup-To: devel@altlinux.ru Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Subject: [devel] Fw: Best Anti-ASN.1 Rant Ever. X-BeenThere: devel@altlinux.ru X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2004 10:08:08 -0000 Archived-At: List-Archive: List-Post: ----- Forwarded message from Jeremy Allison ----- 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/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: From: Alexander Bokovoy To: devel@altlinux.ru Message-ID: <20040211100801.GC5086@sam-solutions.net> Mail-Followup-To: devel@altlinux.ru Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Subject: [devel] Fw: Best Anti-ASN.1 Rant Ever. X-BeenThere: devel@altlinux.ru X-Mailman-Version: 2.1.4 Precedence: list Reply-To: ALT Devel discussion list List-Id: ALT Devel discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Feb 2004 10:08:08 -0000 X-List-Received-Date: Wed, 11 Feb 2004 10:08:08 -0000 X-List-Received-Date: Wed, 11 Feb 2004 10:08:08 -0000 Date: Wed, 11 Feb 2004 10:08:08 -0000 X-Original-Date: Wed, 11 Feb 2004 12:08:01 +0200 X-List-Received-Date: Wed, 11 Feb 2004 10:08:08 -0000 Message-ID: <20040211100808.x4hTN54KQZ0YBapM5ysIYYE8MYjDZtbM4UqiqfzjWnk@z> Archived-At: List-Archive: List-Post: ----- Forwarded message from Jeremy Allison ----- 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/