The openssl asn1parse command can be used to parse ASN.1 input and print its contents in a human-readable text format. In response to certain input encoding errors, it dumps the content of the offending element as hexadecimal, then continues parsing and printing the following elements.

However, all of the following elements in the same sequence will also be printed as hexadecimal, even if well-formed, due to the prior encoding error. Instead, since the input error has been diagnosed and recovered from, following elements should be printed normally.

The bug occurs because the flag dump_cont in the asn1_parse2 function in crypto/asn1/asn1_par.c is never reset after being set. The most obvious fix would be to clear it after printing the hex.

Test case input:

  # dump-cont-bug.hex
  # Demonstrate the 'dump_cont_not_reset' bug in 'asn1_parse2'.
  30 0B                    # SEQUENCE with 11 octets
    01 02                    # BOOLEAN with 2 octets (invalid)
      AB CD                    # Junk
    0C 05                    # UTF8 STRING with 5 octets
      74 68 65 72 65           # "there"

Commands to run:

  $ cat dump-cont-bug.hex | sed 's/#.*//' | xxd -r -p - input.der
  $ openssl asn1parse -inform DER -in input.der

This produces the output:

    0:d=0  hl=2 l=  11 cons: SEQUENCE
    2:d=1  hl=2 l=   2 prim: BOOLEAN           :BAD BOOLEAN:171:[ABCD]
    6:d=1  hl=2 l=   5 prim: UTF8STRING        :there:[7468657265]
                                                     ^^^^^^^^^^^^^

The output ":[7468657265]" is caused by the bug; it should not be there.

The bug has been observed with OpenSSL 1.1.1b and 1.1.1j running on Windows 10, built from source, although I think it is much older and not platform dependent.