The race is on for maintainers of downstream applications

UPDATED The maintainers of OpenSSL, the open source library used by millions of web applications to encrypt communications, have released updates addressing a ‘high’ severity denial of service (DoS) vulnerability.

This issue, which arises from how OpenSSL parses certificates, affects OpenSSL versions 1.0.2, 1.1.1, and 3.0, and was addressed with the release of 1.0.2zd, 1.1.1n, and 3.0.2 yesterday (March 15) afternoon.

The disclosure has serious supply chain implications given that, according to builtWith, OpenSSL delivers the Transport Layer Security (TLS) protocol for at least 2.7 million active websites.

Matt Caswell, a developer at the OpenSSL Software Foundation, told The Daily Swig that, as of yet, “we are not aware of anyone exploiting this in the wild”.

‘Loop forever’

The software-hanging bug leaves cryptographic subsystems at risk from rogue certificates.

“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,” explains an OpenSSL security advisory.

“Internally this function is used when parsing certificates that contain elliptic curve public keys in compressed form or explicit elliptic curve parameters with a base point encoded in compressed form.”


Catch up on the latest internet infrastructure news


The infinite loop can be triggered by crafting a certificate with invalid, explicit curve parameters, according to the OpenSSL project.

“Since certificate parsing happens prior to verification of the certificate signature, any process that parses an externally supplied certificate” is therefore at risk from a DoS attack. “The infinite loop can also be reached when parsing crafted private keys as they can contain explicit elliptic curve parameters.”

Vulnerable scenarios

Anything that parses ASN.1 elliptic curve parameters is potentially at risk, along with “applications that use the BN_mod_sqrt() where the attacker can control the parameter values”, says the advisory.

Matt Caswell said: “Creating a certificate that exploits this bug would require some technical know-how, but is not difficult.

“The most common scenario where this would be a problem would be for a TLS client accessing a malicious server that serves up a problematic certificate. TLS servers may be affected if they are using client authentication (which is a less common configuration) and a malicious client attempts to connect to it.”

Although the update for version 1.0.2 – 1.0.2zd – is for premium users only, the flaw is harder to exploit with this version as “the public key is not parsed during initial parsing of the certificate, which makes it slightly harder to trigger the infinite loop”, says the advisory.

Nevertheless, “any operation which requires the public key from the certificate will trigger the infinite loop”, it continues, with attackers able to use a self-signed certificate to trigger the loop during verification.

Node.js updates incoming

The race is on for maintainers of downstream applications, who were given advance warning of the incoming updates on March 8, to assess how they might be impacted and how urgently they need to update their own frameworks.

This includes JavaScript runtime environment Node.js, which gave its own users a heads-up yesterday (March 14) that it “may be releasing new versions across all of its supported release lines late this week to incorporate upstream patches from OpenSSL” once technical details landed.


DON’T MISS Node.js security: Parse Server remote code execution vulnerability resolved


Writing on his ImperialViolet blog, infosec expert Adam Langley noted that the OpenSSL bug arose because of support for arbitrary curves – as was the case for an earlier Windows signature bypass – despite him being unaware “that anyone has ever used the ability to specify arbitrary curves for anything useful”.

He also wrote: “As an aside, it's interesting to wonder how many CPU decades have been spent fuzzing OpenSSL’s certificate parsing and yet today’s issue wasn't reported before.”

The security flaw was reported to OpenSSL on February 24, 2022 by Tavis Ormandy from Google.

The most damaging bug in the OpenSSL library to date remains the infamous Heartbleed vulnerability of 2014 that enabled attackers to access secret keys, passwords, and sensitive personal information.


This article was updated on March 16 to include a reference to Adam Langley’s OpenSSL bog post and comment from OpenSSL developer Matt Caswell.


RELATED Encryption issues account for minority of flaws in encryption libraries – research