Re: EEYE: Microsoft ASN.1 Library Length Overflow Heap Corruption

[Buck Huppmann <buckh () pobox com>]

On Fri, Feb 13, 2004 at 01:04:31AM -0500, Thor Lancelot Simon wrote:

> 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.

perhaps it doesn't emit BER on the sending side, but on the receiving
end, it probably just hands DER off to a generalized BER decoder, given
that DER is a subset of BER. i'm very probably wrong (and i apologize in
advance and ask that you not flame too intensely in rebuttal), but in
OpenSSL, say, it seems that the decoding functions accept either DER or
more generalized BER. this certainly doesn't prove anything, but

$ perl -ne 'print pack "C", hex $_' | openssl asn1parse -inform DER
0x33 # printable string, constructed encoding--this isn't legal DER
0x80 # indefinite length--illegal DER also, for a printable-string, anyway
0x13 # printable string, primitive encoding
0x81 # 1 length byte follows--this isn't legal DER either, i don't think
0x03 # length: 3 bytes
0x66 # 'f'
0x6f # 'o'
0x6f # 'o'
0x13 # printable string, primitive encoding--this is the distinguished form
0x01 # length: 1 byte
0x10 # '\n'
0x00 # eoc 
0x00 # indicator
    0:d=0  hl=2 l=inf  cons: PRINTABLESTRING   
    2:d=1  hl=3 l=   3 prim: PRINTABLESTRING   :foo
    8:d=1  hl=2 l=   1 prim: PRINTABLESTRING   :
   11:d=1  hl=2 l=   0 prim: EOC               

which says nothing about how Microsoft does it, but i wouldn't assume
they have separate DER and BER parsing routines