An update on the impact of OpenSSL CVE-2022-3602 and CVE-2022-3786 on Akamai's systems

On November 1, 2022, the OpenSSL team published an advisory about two new vulnerabilities, CVE-2022-3786 and CVE-2022-3602. The OpenSSL team rated the severity of both of these vulnerabilities as HIGH.

On the day before the publication of the vulnerability details and the software patches, Akamai published a detailed blog post on how we prepared for the release. After completing our initial analysis at the end of last week, we wanted to take the time now to assure our customers that Akamai's content delivery platform is not impacted by this vulnerability, and customer data is well-protected.

Vulnerability details

The two vulnerabilities in question only affect versions of the OpenSSL library between 3.0.0 and 3.0.6 inclusive. These recent versions are, as of November 2022, only included in the latest versions of certain operating systems, which helps minimize the impact notably.

First, Akamai's content delivery platform and HTTP proxy systems ("Akamai Ghost") are using nonimpacted OpenSSL versions, meaning all such traffic is entirely unaffected. Second, all Akamai systems are taking advantage of industry-standard protection mechanisms — including address space layout randomization (ASLR); stack canaries; and OS features, such as NX memory protection — that would further mitigate the risk of a remote code execution (RCE) attack vector here even if our system had been using OpenSSL version 3.0.x. (The prevalence of such features are one of the reasons why the OpenSSL team downgraded the severity of the vulnerability from CRITICAL to HIGH prior to their announcement.)

It further helps to understand the limited possible impact of these vulnerabilities by analyzing conceivable attack vectors: Since the exploit path is within the certificate validation logic that applies to X.509 name constraints as described in RFC5280, the circumstances of an attack are more immediately applicable in environments where X.509 client certificate validation for mutual TLS is used, although a server-side attack vector remains conceivable in certain very specific use cases.

In general, an attacker needs to generate a certificate containing a subject alternative  name (SAN) specifying an "otherName" field with an OID 1.3.6.1.5.5.7.8.9 ("SmtpUTF8Mailbox") set to a UTF8 punycode email address. In addition, the victim must include and use for certificate validation a certificate from a CA that has enforced a specific name constraint, leading to the validation of that "otherName" punycode email address.

Per the CA/B Forum Baseline Requirements, a public Certification Authority (CA) will not issue public certificates with an "otherName" SAN, and combined with the name constraint requirement, this means the attacker effectively has to provide the CA certificate to the victim and make the victim trust this CA certificate.

In addition, as noted above, the victim needs to run OpenSSL 3.0.x prior to 3.0.7 and, in order to make RCE reasonably feasible, have disabled memory protections.

All in all, a very difficult attack path indeed.

System updates and patching

Even though Akamai's content delivery platform is not affected by this vulnerability, given the ingenuity and motivation of our adversaries and the scale of our global infrastructure footprint, resting on the protections in place would be a dangerous sign of hubris.

When it comes to the protection of our customers, we choose to never be careful enough, which is why we have been actively identifying any and all instances of the use of OpenSSL 3.0.x even in environments or services that are not exposed to the internet and even where, for example, stack protections and other mitigating factors are present.

Any such systems are in the process of being updated on an expedited schedule out of an abundance of caution. We do not anticipate these efforts will lead to downtime or any other impact for customers.

At the same time, we are also working with our third-party providers and service suppliers to assess their respective susceptibilities to this vulnerability. Although we have so far not identified any issues impacting Akamai, we will of course address any problems those providers and suppliers may have where we can.

Summary

Much like everybody else on the internet, we were awaiting the details of the pre-announced vulnerabilities with bated breath. When the OpenSSL Security Announcement was published, our own analysis confirmed the downgraded severity of the vulnerabilities.

Thanks to our preparation in the days before the announcement, we were able to quickly confirm that Akamai's content delivery platform was not affected.

We are confident that our best security practices combined with our ongoing efforts to always keep all our systems up-to-date — whether they are exposed to the internet or not — will continue to protect our customers' data.

Oh, and if you would like to help us do just that, and you enjoy unique challenges in internet infrastructure security at scale, we're hiring!