CVE-2023-0286

Overview

Node.js is a JavaScript runtime built on Chrome's V8 JavaScript engine. It uses an event-driven, non-blocking I/O model and is widely used for web applications and server-side development. Node.js compiles its own copy of OpenSSL from deps/openssl in the Node.js source tree, and the built-in tls and https modules rely on that bundled copy to verify certificate chains, including against certificate revocation lists (CRLs) supplied through the crl option.

A vulnerability (CVE-2023-0286) has been identified in the OpenSSL library bundled with Node.js. OpenSSL parses an X.400 address inside an X.509 GeneralName as one data type, but its public structure definition declared the field as a different type, and GENERAL_NAME_cmp() compares it as that other type. When CRL checking is enabled, an attacker can use this mismatch to make OpenSSL pass arbitrary pointers to memcmp(), which can disclose memory contents or crash the process.

This flaw maps to CWE-843 (Access of Resource Using Incompatible Type, 'Type Confusion'), where software reads data as a type other than the one it was created as. In OpenSSL, the x400Address field was stored as an ASN1_STRING but read by GENERAL_NAME_cmp() as an ASN1_TYPE, whose layout is different, so values an attacker controls in the certificate or CRL end up being used as memory addresses during the comparison.

The vulnerable comparison runs when OpenSSL matches a certificate's CRL distribution point against a CRL, which only happens when CRL checking is enabled. In Node.js, passing a CRL through the crl option of tls.createSecureContext() turns that checking on. In most cases the attacker must supply both the certificate chain and the CRL, neither of which needs a valid signature; if the attacker controls only one, the other must already contain an X.400 address as a CRL distribution point, which is uncommon. Applications most at risk are those that fetch CRLs over the network themselves. This issue affects every Node.js release line from 4.x through 19.x whose bundled OpenSSL is 1.0.2, 1.1.1 or 3.0, up to the versions listed above.

Details

Module Info

• Product: Node.js
• Affected packages: node (bundles OpenSSL under deps/openssl)
• Affected versions: >=4.0.0 <=4.9.1 >=5.0.0 <=5.12.0 >=6.0.0 <=6.17.1 >=7.0.0 <=7.10.1 >=8.0.0 <=8.17.0 >=9.0.0 <=9.11.2 >=10.16.0 <=10.24.1 >=11.9.0 <=11.15.0 >=12.0.0 <=12.22.12 >=13.0.0 <=13.14.0 >=14.0.0 <14.21.3 >=15.0.0 <=15.14.0 >=16.0.0 <16.19.1 >=17.0.0 <=17.9.1 >=18.0.0 <18.14.1 >=19.0.0 <19.6.1
• GitHub repository: https://github.com/nodejs/node
• Published packages: https://nodejs.org/en/download
• Package manager: Not applicable; Node.js is distributed as runtime builds from nodejs.org rather than as a published npm package
• Fixed in: Node.js 14.21.3, 16.19.1, 18.14.1 and 19.6.1 (all February 16, 2023), security releases that upgraded the bundled OpenSSL to 1.1.1t or 3.0.8; Node.js NES v16.20.3 (16.x line, shipped July 30, 2024), a later cumulative build carrying the same fix. The other release lines listed above never received an updated OpenSSL

Vulnerability Info

This High-severity vulnerability is found in the OpenSSL library that Node.js bundles and statically links at deps/openssl, in Node.js releases whose bundled OpenSSL predates 1.1.1t, 3.0.8 or 1.0.2zg. NVD assigns a CVSS v3.1 score of 7.4, and OpenSSL also rates the issue High.

A GeneralName is a tagged union used throughout X.509 for names such as DNS names, email addresses and X.400 addresses, and GENERAL_NAME_cmp() compares two of them by type. For an X.400 address, the parser stored an ASN1_STRING, but the public header declared the field as ASN1_TYPE, and the comparison followed the header. Reading a string structure as an ASN1_TYPE makes the comparison pick up the wrong fields as a length and a data pointer, and those values come from attacker-supplied input. The fix changes the public definition of the x400Address field to ASN1_STRING so that it matches what the parser actually stores; OpenSSL notes that no existing application could have used the old definition successfully. See the OpenSSL 1.1.1 fix commit and the OpenSSL 3.0 fix commit for the exact changes.

With control over the compared values, an attacker gets a limited read primitive through memcmp(): depending on the pointers chosen, the process may reveal whether memory at a given address matches expected content, or crash on an invalid address. NVD scores the confidentiality and availability impact as high and the attack complexity as high, reflecting how much of the input the attacker must control.

Note: Node.js applications that never pass a crl option, and so never enable CRL checking, are not exposed by this issue.

Mitigation

Users of the affected components should apply one of the following mitigations:

• Upgrade to a currently supported Node.js LTS release (22.x or 24.x), both of which bundle OpenSSL 3.5, which includes this fix.
• Where an upgrade is not yet possible, load CRLs only from trusted, verified sources rather than from attacker-reachable locations.
• Leverage a commercial support partner like HeroDevs for post-EOL security support, through Node.js NES.

Credits

• David Benjamin from Google (reporter)
• Hugo Landau from the OpenSSL project (remediation developer)