TL;DR: OpenSSL Project released two new vulnerabilities, CVE-2022-3602 and CVE-2022-3786, which are less severe than previously announced. According to Wiz Research, these buffer overflow vulnerabilities are hard to exploit and require specific exploits per target application; the likelihood of generic, mass exploitation attempts of clients/servers that utilize the OpenSSL 3 library is low. Moreover, Wiz data shows only 1.5% of OpenSSL instances are impacted versions.
*This blog was updated on November 1st, 2022 following OpenSSL Project's patch release.
OpenSSL is a cryptographic library that is universally used for encrypting communications on the Internet. It is widely used by Internet servers, including the majority of HTTPS websites.
OpenSSL has published details of two new High severity vulnerabilities in OpenSSL (official advisory, blog post). One of these vulnerabilities (CVE-2022-3602) was initially announced to be of Critical severity, but OpenSSL later lowered its severity to High due to several mitigating factors (details below). The other vulnerability (CVE-2022-3786) is also deemed to be of High severity.
These vulnerabilities affect OpenSSL versions 3.0.0 and above, as well as any application with an embedded impacted OpenSSL library in the affected version range. Although OpenSSL 3.3 is the current major version, it is still significantly less prevalent than OpenSSL 1, which is not impacted by this vulnerability.
You can also watch this quick 5-minute video summary of the vulnerabilities, including a technical breakdown and thoughts on impact and severity, by Shir Tamari Head of Research @Wiz:
Under very specific conditions, TLS servers and clients running affected versions of OpenSSL may be vulnerable to remote code execution (RCE).
The fault lies in OpenSSL’s X.509 certificate verification process, which is susceptible to two types of buffer overflow: 4-byte (CVE-2022-3602), and variable length (CVE-2022-3786). This flaw is located in the punycode decoder component, which is part of the OpenSSL libcrypto library.
According to OpenSSL, any OpenSSL 3.0 application that verifies X.509 certificates received from untrusted sources should be considered vulnerable, which includes both TLS clients and TLS servers that are configured to use TLS client authentication.
For TLS servers, the vulnerabilities can only be exploited if they are configured to request client authentication and receive a specially-crafted certificate from a malicious client. In other words, this would only affect servers using mutual TLS (mTLS for short): in regular (non-mutual) TLS, only the client authenticates the server’s identity, using a certificate sent by the server. In mTLS, the server also authenticates the client’s identity based on a certificate sent by the client.
As for TLS clients, the vulnerabilities can only be exploited if they connect to an attacker-controlled server, which might happen if a user was phished and convinced to click a malicious link, or if their traffic was being redirected due to a man-in-the-middle (MITM) attack, for example. Additionally, automated clients (e.g. web-crawlers and bots that fetch social media previews) may be made to connect to malicious servers.
Yes, at least one public proof-of-concept (POC) exploit has been made available, but it is intended to crash the vulnerable system rather than allow RCE. More effective POCs may become available as time goes by.
There are several important mitigating factors at play which lower the likelihood of exploitation of these vulnerabilities:
1. Exploitation requires either a certificate authority (CA) to have signed a malicious specially-crafted certificate, or for an application to continue certificate verification despite failure to construct a path to a trusted issuer.
2. Many platforms implement stack overflow protections which would mitigate the risk of remote code execution.
3. Many platforms’ and compilers’ stack layouts are not susceptible to the specific type of buffer overflow allowed by CVE-2022-3602.
4. Buffer overflow vulnerabilities are generally difficult to exploit and usually require specific exploits per target application.
So all in all, an attacker would need to (1) issue a specially-crafted malicious TLS certificate, (2) have it signed by a certificate authority, and (3) identify a server running a vulnerable version of TLS 3, which is (4) configured for mTLS and (5) has no effective mitigations in place to prevent exploitation. This scenario is unlikely but not impossible.
To estimate the potential impact of the vulnerability, we have analyzed hundreds of cloud environments from all major CSPs (AWS, GCP, Azure, OCI, AliCloud) and millions of workloads. The results: over 75% of organizations have at least one impacted instance in their environment. The good news is only 1.5% of OpenSSL instances are impacted versions, whereas 98.5% are older unaffected versions (see figure). This low prevalence can be explained through a quick review of Linux distribution documentation: only newer versions such us Ubuntu 22 and RHEL 9 include OpenSSL 3 in their package manifests.
Although the severity of the OpenSSL vulnerabilities has been reduced to High and we consider them complex for attackers to exploit, we still recommend taking a proactive approach and upgrading to OpenSSL 3.0.7. We recommend taking the following steps to effectively manage patching in your environment:
Identify which assets run impacted versions of OpenSSL.
Prioritize impacted assets in the following order:
Internet-facing assets.
Mission-critical assets: assets with sensitive data, secrets, production services, etc.
Second hop: assets with high privileges or other lateral movement paths that allow an attack to gain access to sensitive assets and services.
Remaining impacted assets.
Patching is always a team sport, especially in cloud-native environments where infrastructure ownership is decentralized.
Map the impacted assets onto owners.
Work with your developers to make sure they are aware of the issue, understand its potential implications, and are your partners in the process.
Have a clear process in place to easily delegate efforts to the teams owning the impacted infrastructure and to track progress.
Don’t forget that patching 3rd-party software in your environment that uses vulnerable OpenSSL versions is also an important part of the mitigation process. OpenSSL can be installed on its own or embedded in other software, and there are many forks of OpenSSL which could be affected by these vulnerabilities depending on what modifications they contain. These possibilities can be summarized in the following diagram:
Remember to monitor the advisories released by software vendors and cloud service providers, and follow their guidance to ensure your environment is properly secured.
Wiz detects impacted OpenSSL packages on all cloud workloads, including VMs, containers, serverless functions, and even virtual appliances. Additionally, customers can use the Wiz Security Graph to focus remediation efforts on the workloads that face the greatest risk (e.g. workloads that are effectively exposed to the internet or have access to sensitive resources).
We are here to help! Cloud security is our passion, so don’t be shy and feel free to reach out to us with any question or feedback. We can also help provide a full agentless scan of your environment to identify and prioritize your vulnerable assets. Wiz is trusted by Salesforce, Morgan Stanley, BMW, Costco, Snowflake, Slack, and more than 30% of the Fortune 100.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。