asn1parse does not enforce proper use of end-of-content (EOC) markers

The openssl asn1parse command parses ASN.1 input and prints the contents in a human-readable form. It also diagnoses a number of violations of the ASN.1 BER format, such as a BOOLEAN value whose length is not 1.

However, a requirement of BER is that an indefinite-length sequence be terminated by an end-of-contents (EOC) marker, and a requirement of both BER and DER is that a definite-length sequence not contain EOC anywhere within it. Quoting X.690-0207, section 8.1.5:

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.

Section 8.1.3.6 describes the indefinite-length form.

Here is a test for asn1parse accepting a missing EOC:

$ cat ndef-missing-eoc.hex
# ndef-missing-eoc.hex
# Indefinite-length sequence with no end-of-contents.
30 15                    # SEQUENCE with 0x15 (21) octets
  30 0f                    # SEQUENCE with 0xf (15) octets
    30 80                    # SEQUENCE with indefinite length
      01 01                    # BOOLEAN with 1 octet
        FF                       # True
      01 01                    # BOOLEAN with 1 octet
        00                       # False
      0C 05                    # UTF8 STRING with 5 octets
        74 68 65 72 65           # "there"
      # NO EOC HERE
  0C 02                    # UTF8 STRING with 2 octets
    48 69                    # "Hi"
$ cat ndef-missing-eoc.hex | sed 's/#.*//' | xxd -r -p - input1.der
$ openssl asn1parse -inform DER -in input1.der
    0:d=0  hl=2 l=  21 cons: SEQUENCE          
    2:d=1  hl=2 l=  15 cons: SEQUENCE          
    4:d=2  hl=2 l=inf  cons: SEQUENCE          
    6:d=3  hl=2 l=   1 prim: BOOLEAN           :255
    9:d=3  hl=2 l=   1 prim: BOOLEAN           :0
   12:d=3  hl=2 l=   5 prim: UTF8STRING        :there
   19:d=1  hl=2 l=   2 prim: UTF8STRING        :Hi
$ echo $?
0

Here is a test for asn1parse accepting a spurious EOC:

$ cat eoc-in-def.hex
# eoc-in-def.hex
# Definite-length sequence containing end-of-contents.
30 08                    # SEQUENCE with 8 octets
  01 01                    # BOOLEAN with 1 octet
    FF                       # True
  00 00                    # End of contents (not allowed here)
  01 01                    # BOOLEAN with 1 octet
    00                       # False
$ cat eoc-in-def.hex | sed 's/#.*//' | xxd -r -p - input2.der
$ openssl asn1parse -inform DER -in input2.der
    0:d=0  hl=2 l=   8 cons: SEQUENCE          
    2:d=1  hl=2 l=   1 prim: BOOLEAN           :255
    5:d=1  hl=2 l=   0 prim: EOC               
    7:d=1  hl=2 l=   1 prim: BOOLEAN           :0
$ echo $?
0

Both test commands exit with code 0 without any error indication. Ideally, they should somehow indicate there is a problem.

The man page for asn1parse doesn't promise to diagnose invalid input, but missing or spurious EOC seems like a fairly substantial deviation from the specified format, at least on par with a BOOLEAN that is too long, so I thought I'd file this for consideration.

I have observed this behavior with OpenSSL 1.1.1b and 1.1.1j running on Windows 10, built from source.

Start by reproducing the two openssl asn1parse commands with ndef-missing-eoc.hex and eoc-in-def.hex, then trace the asn1parse parser entry point. Done means both malformed inputs produce an error indication and nonzero exit status, with regression coverage for both cases.