SIGSEGV in sc_asn1_read_tag when parsing malformed ASN.1 data about opensc HOT 4 CLOSED

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.

from opensc.

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)?

from opensc.

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 [email protected]

from opensc.

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?

from opensc.