Bugtraq mailing list archives
Re: EEYE: Microsoft ASN.1 Library Length Overflow Heap Corruption
From: David Wilson <David.Wilson () isode com>
Date: Fri, 13 Feb 2004 23:14:11 +0000
That's not actually correct. Most network protocols use the "Distinguished Encoding Rules" (DER) not the "Basic Encoding Rules" (BER). BER is an abomination and should never, ever have been in the standard; the only protocol commonly used over IP that uses BER is LDAP, because it descends from DAP, which used BER. So you can't reasonably assume that if it uses ASN.1, it uses BER. That's presumably why Microsoft left certain ASN.1-using network services turned on.
DER is not a transfer encoding syntax. It's purpose is to give the same sequence of octets for a given abstract value (as does CER - Canonical Encoding Rules). LDAP, OSI, SNMP etc. all use BER, albeit with restriction in some cases (e.g. no use of indefinite length encoding). The cryptographic message syntax (RFC 3369) requires DER for some elements, but specifically allows BER overall. [OSI can use PER - Packed Encoding Rules - but that is a whole different ballgame]. DER is used for signing, not for transfer. I.e. if you get an ASN.1 value in protocol (whatever transfer syntax) you need to re-encode the value (paying attention to the ASN.1 type) as DER to generate the hash. In any case DER is a subset of BER (as is CER). The particular vulnerability in question arises in the encoding of primitive elements, where DER and BER are the basically the same (except that with DER you are required to specify the length field in the minimum amount of space, which is not the case for BER). The bottom line is: given a PDU or object encoded in DER, you would use a BER decoder on it. I'm not sure what the issue is which causes BER to be an "abomination" while DER is OK. cheers -- David Wilson <David.Wilson () isode com> Isode Limited
Current thread:
- Re: EEYE: Microsoft ASN.1 Library Length Overflow Heap Corruption, (continued)
- Re: EEYE: Microsoft ASN.1 Library Length Overflow Heap Corruption Peter Pentchev (Feb 12)
- Re: EEYE: Microsoft ASN.1 Library Length Overflow Heap Corruption Timothy J . Miller (Feb 12)
- Re: EEYE: Microsoft ASN.1 Library Length Overflow Heap Corruption Florian Weimer (Feb 16)
- RE: EEYE: Microsoft ASN.1 Library Length Overflow Heap Corruption Rainer Gerhards (Feb 10)
- RE: EEYE: Microsoft ASN.1 Library Length Overflow Heap Corruption Tina Bird (Feb 11)
- RE: EEYE: Microsoft ASN.1 Library Length Overflow Heap Corruption Alun Jones (Feb 11)
- RE: EEYE: Microsoft ASN.1 Library Length Overflow Heap Corruption Rainer Gerhards (Feb 11)
- Re: EEYE: Microsoft ASN.1 Library Length Overflow Heap Corruption Steve Friedl (Feb 12)
- Re: EEYE: Microsoft ASN.1 Library Length Overflow Heap Corruption Thor Lancelot Simon (Feb 13)
- Re: EEYE: Microsoft ASN.1 Library Length Overflow Heap Corruption Buck Huppmann (Feb 16)
- Re: EEYE: Microsoft ASN.1 Library Length Overflow Heap Corruption David Wilson (Feb 16)
- Re: EEYE: Microsoft ASN.1 Library Length Overflow Heap Corruption Sam Schinke (Feb 12)
- RE: EEYE: Microsoft ASN.1 Library Length Overflow Heap Corruption Drew Copley (Feb 12)
- RE: EEYE: Microsoft ASN.1 Library Length Overflow Heap Corruption Boyce, Nick (Feb 13)
- Re: EEYE: Microsoft ASN.1 Library Length Overflow Heap Corruption Michael Shigorin (Feb 16)
- Re: EEYE: Microsoft ASN.1 Library Length Overflow Heap Corruption Joshua Levitsky (Feb 16)
- RE: EEYE: Microsoft ASN.1 Library Length Overflow Heap Corruption Bill Gallagher (Feb 15)