The OpenSSL project released a patch for two high severity vulnerabilities in the world\u2019s most widely used cryptographic library. The project\u2019s 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 verificationThe 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.\u201cAny OpenSSL 3.0 application that verifies X.509 certificates received from untrusted sources should be considered vulnerable,\u201d the OpenSSL maintainers said in an advisory. \u201cThis includes TLS clients and TLS servers that are configured to use TLS client authentication.\u201dMost 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\u2019re able to insert themselves between the application and the server and hijack the application\u2019s 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 severityThe OpenSSL project doesn\u2019t 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 \u201ccommon 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.\u201dBuffer 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\u2019s a 4-byte stack overflow and CVE-2022-3786 as high severity because the attacker can\u2019t 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 \u2013 including general purpose OS vendors that bundle OpenSSL such as Linux distributions \u2013 the severity was revised.\u201cFirstly, 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,\u201d the project said in its advisory. \u201cSecondly, many modern platforms implement stack overflow protections which would mitigate against the risk of remote code execution and usually lead to a crash instead.\u201dThat doesn\u2019t 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 \u201ccommon configurations and which are also likely to be exploitable\u201d criteria for critical issues were no longer being met by this vulnerability.OpenSSL 3.0 doesn\u2019t have wide adoption yetOn 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\u2019s 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 \u2013 vulnerabilities inherited from third-party software dependencies \u2013 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).\u201cWhile 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,\u201d Brian Fox, CTO of software supply chain security firm Sonatype, tells CSO via email. \u201cThe 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.\u201dRed Hat has released an advisory and released OpenSSL patches for Red Hat Enterprise Linux 9. The company rates the flaws\u2019 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.