2023-07-05, 11:25–11:45 (Europe/Paris), Amphitheater
Edition of DER encoded ASN.1 structures is a pretty tedious work when done manually.
Solutions to this problem exist. For instance, der-ascii  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  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  & .
Remember the OpenSSL vulnerability referenced as CVE-2022-0778 (15/03/2022)...
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
The ASN.1 cryptographic structures we are considering here are often complex
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
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
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
I manage the technical team that is behind AS197692 at Conostix S.A. in Luxembourg .
I've been working with free and opensource software on a daily basis for more than 25 years.
I contributed to the cleanup and enhancement efforts done on ssldump  lately.
I particularly enjoy tinkering with open and, not so open, hardware.