SIGSEGV in sc_asn1_read_tag when parsing malformed ASN.1 data

[FluffyKaon]

The issue is on this line:
https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/asn1.c#L68

When passing in an object starting with 00 or FF the function returns SC_SUCCESS with an uninitialized tag_out and taglen.
Most caller like pgp_enumerate_blob will call the function again after adding the uninitialized length to the pointer resulting in a SIGSEGV.

I can see three ways to fix it (I'd prefer the first one):
A) Don't treat 00 or FF as special tag values (I don't see why they should be by reading ITU X.690 but I might have missed something).

B) Return an error instead of SC_SUCCESS

C) Set tag_out = 0, tag_len = 0 and modify all callers so they don't enter an infinite loop in that situation (least favored fix).

What is the best way to fix it? Send you a patch?

[LudovicRousseau]

I also thing this code is suspect and dangerous.
But I have no idea what to do.

The best way to fix this is to understand where/when this special case is used in OpeSC. But this would involve using many different cards with many different ASN.1 encoded data. Not easy.

[frankmorgner]

ASN.1 formatted data that is padded with '0x00' to fill a fixed size file is very common on smart cards. Would sc_asn1_read_tag still ignore the junk at the end or would it rather throw an error (which would be wrong)?

[dengert]

On 10/1/2014 4:05 PM, Frank Morgner wrote:

ASN.1 formatted data that is padded with '0x00' to fill a fixed size file is very common on smart cards. Would sc_asn1_read_tag still ignore the junk at the end or would it rather throw an error
(which would be wrong)?

http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf

defines an "End of Content" for BER.

8.1.5 End-of-contents octets
The end-of-contents octets shall be present if the length is encoded as specified in 8.1.3.6, otherwise they shall not be
present.
The end-of-contents octets shall consist of two zero octets.
NOTE – The end-of-contents octets can be considered as the encoding of a value whose tag is universal class, whose form is
primitive, whose number of the tag is zero, and whose contents are absent, thus:
End-of-contents Length Contents

A Layman's Guide to a Subset of ASN.1, BER, and DER
that can be found in a number of places also talks about end-of-contents

http://luca.ntop.org/Teaching/Appunti/asn1.html

3.3 Constructed, indefinite-length method
In both cases, it is 00 00, and only if indefinite-length is used.

Most of the ASN.1 we use is DER.

Does the length of the top most ASN.1 include the length of padding?
In which case it is not valid ASN.1 and should be an error.

Or is the padding after the last of the ASN.1 bytes to fill the buffer?
i.e. the length of the buffer is larger then the ASN.1 data.

This could OK, as the padding is not part of the ASN.1
OpenSC could relax the restriction that the length passed to the
decode not have any left over bytes. or all the leftove rbytes
are zeros.)

—
Reply to this email directly or view it on GitHub #190 (comment).

Douglas E. Engert DEEngert@gmail.com

[frankmorgner]

It would be safe to do the following:

• C*) Set tag_out = 0, tag_len = 0 before calling sc_asn1_parse. sc_asn1_parse can be left untouched then.

Could you provide a patch?