Edition of DER encoded ASN.1 structures is a pretty tedious work when done manually. Solutions to this problem exist. For instance, der-ascii [0] is a tool written in Go that helps with back and forth conversions from/to DER structures to/from a textual representation using a custom defined language. I present a somehow short Perl script [1] that leverages the OpenSSL configuration language along with the ASN1_generate_nconf(3) function in order to achieve the same goal with almost no dependencies apart from Perl and OpenSSL. This tool can be used to ease the exploitation of CVE-2022-0778 [2] & [3]. [0] https://github.com/google/der-ascii [1] https://github.com/wllm-rbnt/asn1template [2] https://www.openssl.org/news/secadv/20220315.txt [3] https://github.com/drago-96/CVE-2022-0778#using-asn1-templates 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.