CVE-2023-0286: X.400 address type confusion in X.509 GeneralName. What exactly does it mean? (8th Feb 2023)

Preface: What is the benefits of corrective action. A motivation to maintain sustainability.

Background: Background: X.509 describes an approach to providing and managing authentication using asymmetric cryptography, generally referred to as Public Key Infrastructure (PKI).
If X.400 defined authentication mechanism using x.509 PKI:
It enhance end to end services for content integrity, message origin authentication and message sequence integrity.

Certificate extensions were introduced in version 3 of the X. 509 standard for certificates. These v3 extensions allow certificates to be customized to applications by supporting the addition of arbitrary fields in the certificate.

OpenSSL itself uses the GENERAL_NAME_cmp function for two purposes:
1) Comparing CRL distribution point names between an available CRL and a CRL distribution point embedded in an X509 certificate
2) When verifying that a timestamp response token signer matches the timestamp authority name (exposed via the API functions TS_RESP_verify_response and TS_RESP_verify_token) .

Vulnerability details: There is a type confusion vulnerability relating to X.400 address processing inside an X.509 GeneralName. X.400 addresses were parsed as an ASN1_STRING but the public structure definition for GENERAL_NAME incorrectly specified the type of the x400Address field as ASN1_TYPE. This field is subsequently interpreted by the OpenSSL function GENERAL_NAME_cmp as an ASN1_TYPE rather than an ASN1_STRING. When CRL checking is enabled (i.e. the application sets the X509_V_FLAG_CRL_CHECK flag), this vulnerability may allow an attacker to pass arbitrary pointers to a memcmp call, enabling them to read memory contents or enact a denial of service. In most cases, the attack requires the attacker to provide both the certificate chain and CRL, neither of which need to have a valid signature. If the attacker only controls one of these inputs, the other input must already contain an X.400 address as a CRL distribution point, which is uncommon. As such, this vulnerability is most likely to only affect applications which have implemented their own functionality for retrieving CRLs over a network.

My observation: Whether the attacker use a vulnerability exploit method similar to CVE-2020-1971 as an attack?
OpenSSL’s s_server, s_client and verify mechanism have support for the “-crl_download” option which implements automatic CRL downloading and this attack has been demonstrated to work against those mechanism. The way is that affected versions of OpenSSL cannot parse or construct correct encodings of EDIPARTYNAME. However it is possible to construct a malformed EDIPARTYNAME that OpenSSL’s parser will accept and hence trigger this attack.

Official announcement: For details, see the link (below):

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.