Remember the OpenSSL vulnerability referenced as CVE-2022-0778 (15/03/2022)...

https://www.openssl.org/news/secadv/20220315.txt

Here is an excerpt from it:

"The BN_mod_sqrt() function, which computes a modular square root, contains a
bug that can cause it to loop forever for non-prime moduli.

[...] used when parsing certificates that contain elliptic curve public keys in
compressed form [...]

It is possible to trigger the infinite loop by crafting a certificate that has
invalid explicit curve parameters. [...]

Since certificate parsing happens prior to verification of the certificate
signature, any process that parses an externally supplied certificate may thus
be subject to a denial of service attack. [...]

Thus vulnerable situations include:

 - TLS clients consuming server certificates
 - TLS servers consuming client certificates
 - Hosting providers taking certificates or private keys from customers
 - Certificate authorities parsing certification requests from subscribers
 - Anything else which parses ASN.1 elliptic curve parameters
[...]"

Successful exploitation of CVE-2022-0778 can be done in 3 steps:
1. Generate EC parameters that have some interesting properties as defined in the vulnerability description
2. Create or modify an already existing encoded ASN.1 cryptographic structure using these parameters
3. Submit the structure to a service that uses a vulnerable OpenSSL library

This presentation is about step 2. .

The ASN.1 cryptographic structures we are considering here are often complex
nested structures.

The problem lies in the fact that such ASN.1 cryptographic structures are
encoded using a binary format (DER - Distinguished Encoding Rules) that follows
a Type-Length-Value (TLV) logic. Each member of the structure is encoded as its
type identifier, followed by its total length (its own length along with the
length of its sub-members, and finally, its value, including the one of all its
sub-members).

As an example, here is an ASN.1 sequence containing 2 integers:

    SEQUENCE:
        INTEGER:0x12
        INTEGER:0x34

Its DER representation can be dissected as this:

          /--> type: SEQUENCE
          /  /--> length: 6 bytes
          /  /  /***************/--> value: the two DER encoded INTEGERs
00000000  30 06 02 01 12 02 01 34                           |0......4|
                /  /  /  /  /  /--> value: 0x34
                /  /  /  /  /--> length: 1 byte
                /  /  /  /--> type: INTEGER
                /  /  /--> value: 0x12
                /  /--> length: 1 byte
                /--> type: INTEGER

The edition process of such binary structure is error prone. One need to keep
track of the modifications made to inner objects in order to reflect length
updates to the outer surrounding objects.
For instance, we could replace the second INTEGER in previous example, with a
longer INTEGER (2 bytes instead of 1) with for value 0x3456:

    SEQUENCE:
        INTEGER:0x12
        INTEGER:0x3456

This means that the second integer has now a length of 2 bytes and that the
encoded length of the surrounding sequence has to be incremented.

             /--> Outer SEQUENCE is now 7 bytes long
             /              /--> second INTEGER in outer SEQUENCE is now 2 bytes long
00000000  30 07 02 01 12 02 02 34  56                       |0......4V|

Simple structures as the one from this example are easy to edit manually with
an hex editor. Larger structures composed of multiple depth of nested
sub-structures are a pain to edit. A single mistake would make the whole
structure unusable.

This presentation is about a tool that predates existing solutions such as
der-ascii, and that I dusted off when CVE-2022-0778 was announced last
year.