Come posso disiscrivermi da questa newsletter??
2009/3/1 Luca Milanesio <l...@milanesio.org> > Dear Stephen Henson, > > I came into the same issue as Bryn about nested ASN.1 string parsing in > OpenSSL since 0.9.7h. > > I understand the limit for infinite nesting in OCTET STRINGs but I came > into an issue where it seems that even a single level nesting is still > refused in ASN.1 parsing. > > Here's a small chunk of the ASN.1 encoding of the issue: > 306:d=3 hl=2 l=inf cons: SEQUENCE > 308:d=4 hl=2 l= 9 prim: OBJECT :pkcs7-data > 319:d=4 hl=2 l= 29 cons: SEQUENCE > 321:d=5 hl=2 l= 9 prim: OBJECT :aes-128-cbc > 332:d=5 hl=2 l= 16 prim: OCTET STRING [HEX > DUMP]:1C93787FF2C2F641917317E2191EEBD1 > 350:d=4 hl=2 l=inf cons: cont [ 0 ] > 352:d=5 hl=2 l=inf cons: OCTET STRING > 354:d=6 hl=2 l= 16 prim: OCTET STRING [HEX > DUMP]:5149BDAC59825B2875FE06A8BC4682E2 > 372:d=6 hl=2 l= 0 prim: EOC > 374:d=5 hl=2 l= 0 prim: EOC > 376:d=4 hl=2 l= 0 prim: EOC > > Even though the maximum OCTET STRING nesting is just "one level" ... I have > the following error in "openssl pkcs7" command: > (I have added some extra traces) > > asn1_template_ex_d2i(): p=136276730 > ASN1_item_ex_d2i(): p=136276730, len=78, type=6 'NDEF_SEQUENCE', tag=16 > 'SEQUENCE' > ASN1_get_object(): p=136276732 + *plength=0 (inf=TRUE) tag=16 'SEQUENCE'> > omax=78 + *pp=136276730 (136276732 > 136276808) > asn1_template_ex_d2i(): p=136276732 > ASN1_item_ex_d2i(): p=136276732, len=76, type=0 'PRIMITIVE', tag=6 'OBJECT' > asn1_d2i_ex_primitive(): p=136276732, plen=128, utype=6 'OBJECT', > inf=FALSE, cst=FALSE > ASN1_get_object(): p=136276734 + *plength=9 (inf=FALSE) tag=6 'OBJECT'> > omax=76 + *pp=136276732 (136276743 > 136276808) > asn1_template_ex_d2i(): p=136276743 > ASN1_item_ex_d2i(): p=136276743, len=65, type=1 'SEQUENCE', tag=16 > 'SEQUENCE' > ASN1_get_object(): p=136276745 + *plength=29 (inf=FALSE) tag=16 'SEQUENCE'> > omax=65 + *pp=136276743 (136276774 > 136276808) > asn1_template_ex_d2i(): p=136276745 > ASN1_item_ex_d2i(): p=136276745, len=29, type=0 'PRIMITIVE', tag=6 'OBJECT' > asn1_d2i_ex_primitive(): p=136276745, plen=135313541, utype=6 'OBJECT', > inf=FALSE, cst=FALSE > ASN1_get_object(): p=136276747 + *plength=9 (inf=FALSE) tag=6 'OBJECT'> > omax=29 + *pp=136276745 (136276756 > 136276774) > asn1_template_ex_d2i(): p=136276756 > ASN1_item_ex_d2i(): p=136276756, len=18, type=0 'PRIMITIVE', tag=-4 > '(unknown)' > asn1_d2i_ex_primitive(): p=136276756, plen=9, utype=-4 '(unknown)', > inf=FALSE, cst=FALSE > ASN1_get_object(): p=136276758 + *plength=16 (inf=FALSE) tag=4 'OCTET > STRING'> omax=18 + *pp=136276756 (136276774 > 136276774) > asn1_template_ex_d2i(): p=136276774 > ASN1_item_ex_d2i(): p=136276774, len=34, type=0 'PRIMITIVE', tag=4 'OCTET > STRING' > asn1_d2i_ex_primitive(): p=136276774, plen=-1074138592, utype=4 'OCTET > STRING', inf=FALSE, cst=FALSE > ASN1_get_object(): p=136276776 + *plength=0 (inf=TRUE) tag=0 'EOC'> omax=34 > + *pp=136276774 (136276776 > 136276808) > ----- > asn1_collect(): (*in)=136276776, len=32, inf=TRUE > ----- > ASN1_get_object(): p=136276778 + *plength=0 (inf=TRUE) tag=4 'OCTET > STRING'> omax=32 + *pp=136276776 (136276778 > 136276808) > unable to load PKCS7 object > 6263:error:0D06A0C5:asn1 encoding routines:ASN1_COLLECT:nested asn1 > string:tasn_dec.c:1210: > 6263:error:0D078089:asn1 encoding routines:ASN1_ITEM_EX_D2I:missing > eoc:tasn_dec.c:484:Type=PKCS7_ENC_CONTENT > 6263:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested > asn1 error:tasn_dec.c:768:Field=enc_data, Type=PKCS7_ENVELOPE > 6263:error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested > asn1 error:tasn_dec.c:768: > 6263:error:0D08403A:asn1 encoding routines:ASN1_TEMPLATE_EX_D2I:nested asn1 > error:tasn_dec.c:597:Field=d.enveloped, Type=PKCS7 > > What do you think about that ? > > P.S. Obviously by enabling OPENSSL_ALLOW_NESTED_ASN1_STRINGS the problem is > bypassed because of the recursive behavior of asn_collect() function. > > Thank you in advance for your help. > > Luca. > > > Hi, >> >> Thanks a lot for the prompt and clear response - much appreciated. >> It turned out that the apparent nested string was caused by a mismatch >> between the ASN.1 definition in the parser and the actual ASN.1 >> structure being parsed. >> Thanks again, >> >> Bryn >> -----Original Message----- >> From: Dr. Stephen Henson [mailto:st...@openssl.org] Sent: Thursday, 28 >> June 2007 1:07 AM >> To: Williams Bryn-R40716 >> Cc: openssl-users@openssl.org >> Subject: Re: Nested ASN1 strings and OPENSSL_ALLOW_NESTED_ASN1_STRINGS >> >> On Tue, Jun 26, 2007, Williams Bryn-R40716 wrote: >> >> > Hi, >> > > A team in our organisation has a small ASN.1 decoding example that > >> works with openssl 0.9.7g, but not with any more recent release. The > >> reason seems to be that the ASN.1 structure in question includes > (perhaps >> > wrongly) a nested ASN.1 string, which is no longer supported by >> default. >> > > I see from the commit logs that the change to conditionalise this in > >> tasn_dec.c was made prior to openssl-0.9.7h by Dr. Stephen Henson with >> >> > the comment "Don't attempt to parse nested ASN1 strings by default" >> > (code included below). >> > > If we recompile openssl (e.g. 0.9.8e) with > >> OPENSSL_ALLOW_NESTED_ASN1_STRINGS then our example works. However, > given >> that this has been disabled by default since 2005 I assume that > this is >> not normally required, annd perhaps should be taken as an > indication that >> we have a bad ASN.1 structure or are parsing it >> incorrectly. >> > > I was hoping someone (Dr Henson...?) could help me to understand why > >> this change was made, and in what circumstances it's appropriate to > >> recompile with OPENSSL_ALLOW_NESTED_ASN1_STRINGS. >> > >> Well the standards technically allow constructed string types to be >> nested to arbitrary depth. This is potentially a problem for recursive >> parsers especially if the stack size is limited. >> >> I've never come across an example of such a string except one >> specifically constructed as an example. I created some pathological >> cases for an ASN1 testing suite: before the above change they would >> crash the parser. >> >> In some structures (such as certificates) they are illegal anyway. >> >> The normal use of constructed strings is for streaming purposes and that >> can be handled using a single level of nesting: which OpenSSL can >> process. >> >> If the input data comes from a trusted source then it is OK to recompile >> with OPENSSL_ALLOW_NESTED_ASN1_STRINGS. From an unstrusted source it >> could be a security hole. >> >> I'd be interested to know what kind of structure you have which includes >> a string with more than one level of nesting. >> >> Steve. >> -- >> Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL >> project core developer and freelance consultant. >> Funding needed! Details on homepage. >> Homepage: http://www.drh-consultancy.demon.co.uk >> ______________________________________________________________________ >> OpenSSL Project http://www.openssl.org >> User Support Mailing List openssl-users@openssl.org >> Automated List Manager majord...@openssl.org >> >> > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org >
