OpenSSL project patches two vulnerabilities but downgrades severity

The OpenSSL project released a patch for two high severity vulnerabilities in the world’s most widely used cryptographic library. The project’s maintainers warned users since last week to prepare for a critical patch on November 1, but the severity has since been downgraded following additional testing.

Organizations should still determine which of their applications and servers are impacted and deploy the patches as soon as possible. The vulnerabilities affect all versions of OpenSSL 3.0, which has been available since last year.

Buffer overflows in X.509 certificate verification

The two vulnerabilities, tracked as CVE-2022-3786 and CVE-2022-3602, are buffer overflow conditions in the punycode decoding functionality that was first introduced in OpenSSL 3.0.0 in September 2021. Punycode is a system for representing Unicode characters as ASCII and is used for example to represent internationalized domain names in the DNS system. In OpenSSL the vulnerable code is used for processing email address name constraints in X.509 certificates, also commonly known as SSL/TLS certificates.

“Any OpenSSL 3.0 application that verifies X.509 certificates received from untrusted sources should be considered vulnerable,” the OpenSSL maintainers said in an advisory. “This includes TLS clients and TLS servers that are configured to use TLS client authentication.”

Most widely used encrypted communication protocols such as HTTPS rely on clients, such as browsers or applications, checking the identity of the servers they connect to by validating their certificates. In such a scenario, an application would have to connect to a server that would present a maliciously crafted certificate for either of these vulnerabilities to be exploited. An attacker could also potentially force this condition with a man-in-the-middle (MitM) attack where they’re able to insert themselves between the application and the server and hijack the application’s requests.

In cases where servers are configured to use client authentication, meaning the server also validates the identity of the client by checking a certificate they present, servers would be vulnerable, too.

One OpenSSL flaw downgraded from critical to high severity

The OpenSSL project doesn’t use the CVSS vulnerability scoring system. Instead, it has its own severity ranking system described in its security policy. According to the policy, critical issues are those that affect “common configurations and which are also likely to be exploitable. Examples include significant disclosure of the contents of server memory (potentially revealing user details), vulnerabilities which can be easily exploited remotely to compromise server private keys, or where remote code execution is considered likely in common situations.”

Buffer overflows can theoretically result in remote code execution, but this is highly dependent on the conditions needed to trigger it and the various mitigations used on a particular platform or system.

Initially, the maintainers viewed CVE-2022-3602 as critical because it’s a 4-byte stack overflow and CVE-2022-3786 as high severity because the attacker can’t control the content of the overwrite. However, after further discussion and testing done together with the organizations that were pre-notified of the vulnerability details – including general purpose OS vendors that bundle OpenSSL such as Linux distributions – the severity was revised.

“Firstly, we had reports that on certain Linux distributions the stack layout was such that the 4 bytes overwrote an adjacent buffer that was yet to be used and therefore there was no crash or ability to cause remote code execution,” the project said in its advisory. “Secondly, many modern platforms implement stack overflow protections which would mitigate against the risk of remote code execution and usually lead to a crash instead.”

That doesn’t mean there are no situations, configurations, and platforms where the flaw can easily lead to remote code execution. OpenSSL is distributed as code and can run on a large variety of platforms, including embedded systems. Applications can also bundle it directly and link to it statically or can use the library included by the OS, if the OS bundles it. However, the maintainers felt that its “common configurations and which are also likely to be exploitable” criteria for critical issues were no longer being met by this vulnerability.

OpenSSL 3.0 doesn’t have wide adoption yet

On the server side, the adoption of OpenSSL 3.0 is not yet very high. According to Censys, a company that scans the entire internet IP space and gathers information about running services, almost 1.8 million unique hosts on the Internet have one or more services using OpenSSL. Only around 7,000 (0.4%) of those run a version of OpenSSL greater than or equal to version 3.0.0. Furthermore, of those running OpenSSL 3.0 only a subset likely perform client-side authentication and would be vulnerable.

Of course, this telemetry only covers servers accessible from the internet and not those on internal networks, which could also be easily reachable by attackers who gain entry to a network. Cloud and security firm Akamai performed its own scans on customer networks and found that around half of them had at least one machine with at least one process using a vulnerable OpenSSL version. The percentage of machines that used a vulnerable OpenSSL version on those networks ranged from 0.2% to 33% with a median of 6.1%.

Since these vulnerabilities are more likely to be exploitable on clients rather than on servers, it’s much harder to determine how big the impact is when it comes to client applications that use OpenSSL to connect to servers. This can be considered a transitive vulnerability – vulnerabilities inherited from third-party software dependencies – for many applications and these can be very hard for organizations to track until efforts like software bill of materials (SBOMs) see wider adoption in the industry.

Fortunately, an important limiting factor for this exploit is that it can only occur after the issuer of the certificate has been validated. This means that in most cases, if certificate validation is enforced properly, attackers would have to obtain a maliciously crafted certificate from a trusted certificate authority (CA).

“While memory overflow bugs can lead to worst case scenarios, the details of this particular vulnerability seem to indicate that the level of difficulty for an exploit is very high,” Brian Fox, CTO of software supply chain security firm Sonatype, tells CSO via email. “The vulnerability requires a malformed certificate that is trusted or signed by a naming authority. That means that authorities should be able to quickly prevent certificates designed to target this vulnerability from being created, further limiting the scope.”

Red Hat has released an advisory and released OpenSSL patches for Red Hat Enterprise Linux 9. The company rates the flaws’ impact as Important and said that neither SELinux nor Kpatch mitigate them.

Organizations should immediately update OpenSSL on their systems or in their applications to version 3.0.7 released Tuesday. The project also released OpenSSL 1.1.1s at the same time, but this is a bug fix release that is not related to these vulnerabilities. The OpenSSL 1.1.x branch is not affected and is still supported until September 2023, but the project maintainers advise application developers to always use the latest version in their applications, namely 3.0.7 at this time.