CVE-2022-3786 and CVE-2022-3602: Two High-Severity Buffer Overflow Vulnerabilities in OpenSSL Fixed

Post Syndicated from Rapid7 original https://blog.rapid7.com/2022/11/01/cve-2022-3786-and-cve-2022-3602-two-high-severity-buffer-overflows-in-openssl-fixed/

CVE-2022-3786 and CVE-2022-3602: Two High-Severity Buffer Overflow Vulnerabilities in OpenSSL Fixed

The Rapid7 research team will update this blog post as we learn more details about this vulnerability and its attack surface area. We expect to update this page next by 3 PM EDT on November 1, 2022.

The OpenSSL project released version 3.0.7 on November 1, 2022, to address CVE-2022-3786 and CVE-2022-3602, two high-severity vulnerabilities affecting OpenSSL’s 3.0.x version stream discovered and reported by Polar Bear and Viktor Dukhovni. OpenSSL is a widely used open-source cryptography library that allows for the implementation of secure communications online; this includes generating public/private keys and use of SSL and TLS protocols. (Currently, only the 1.1.1 and 3.0 version streams of OpenSSL are supported). The OpenSSL team warned maintainers and users on October 25 that a critical flaw was on the way — only the second to ever impact the product. Upon release, however, neither vulnerability carried a critical severity rating.

CVE-2022-3786 and CVE-2022-3602 are buffer overflow vulnerabilities in OpenSSL versions below 3.0.7 that both rely on a maliciously crafted email address in a certificate. They differ in two crucial ways: CVE-2022-3786 can overflow an arbitrary number of bytes on the stack with the "." character (a period), leading to denial of service, while CVE-2022-3602 allows a crafted email address to overflow exactly four attacker-controlled bytes on the stack. OpenSSL has a blog available here.

According to the OpenSSL advisory, the vulnerability occurs after certificate verification and requires either a CA to have signed the malicious certificate or for the application to continue certificate verification despite failure to construct a path to a trusted issuer. In other words, exploitability is significantly limited:

  • In the case where a server is the target (a webserver, database server, mail server, etc): The server must first request client authentication as part of a mutual authentication configuration. This is an unusual configuration, and usually specialized to higher-security use cases.
  • In the case where a client is the target (web browser, email reader, database connector, etc): The attacker would need to first coerce a vulnerable client to connect to a malicious server. This could be done through impersonation (MitM on the network, hijacking an existing resource, etc) or by providing an incentive for a person to click a link (through phishing, watering holes, etc).

For both scenarios, these kinds of attacks do not lend themselves well to widespread exploitation.

Once again, these vulnerabilities only affect the OpenSSL 3.0.x version stream, which has not yet been widely adopted. We are not aware of any exploitation in the wild at the time of the vulnerability’s release on November 1, 2022.

Affected products

  • OpenSSL versions 3.0.0 to 3.0.6 (fixed in 3.0.7)

A broad array of popular distributions and technologies use OpenSSL in their offerings, including many widely used Linux distributions. OpenSSL 1.x, which is unaffected, is still the most popular version stream in use. Major distribution maintainers will likely have individual updates out quickly, but we expect a long tail of advisories and trailing fixes as vendors update additional implementations. Community tracking efforts like this one from Royce Williams, or government tracking efforts like this one from NCSC-NL may also be helpful for following individual vendor impact or remediation communications.

Mitigation guidance

Organizations that are running an affected version of OpenSSL should update to 3.0.7 when practical, prioritizing operating system-level updates and public-facing shared services with direct dependencies on OpenSSL. Emergency patching is not indicated.

Rapid7 customers

Our engineering team is in the process of developing both authenticated and unauthenticated vulnerability checks to allow InsightVM and Nexpose customers to assess their exposure to CVE-2022-3786 and CVE-2022-3602. We expect these checks to be available in a content release today (November 1, 2022).

In the meantime, InsightVM customers can use Query Builder with the query software.description CONTAINS OpenSSL 3 to find potentially affected assets. Nexpose and InsightVM customers can create a Dynamic Asset Group with a filtered asset search looking for Software name contains OpenSSL 3.

Additionally, Nexpose and InsightVM customers can use the following SQL query in a SQL Query Export (Security Console -> Reports -> SQL Query Export) to identify whether they have (any version of) OpenSSL in their environments. This query will produce a CSV file with a list of assets containing installed software with “openssl” in its title, and the corresponding version previously found in scans or Insight Agent-based assessments:

SELECT da.sites AS "Site_Name", da.ip_address AS "IP_Address", da.mac_address AS "MAC_Address", da.host_name AS "DNS_Hostname", ds.vendor AS "Vendor", ds.name AS "Software_Name", ds.family AS "Software_Family", ds.version AS "Software_Version", ds.software_class AS "Software_Class" FROM dim_asset_software das JOIN dim_software ds USING(software_id) JOIN dim_asset da ON da.asset_id = das.asset_id WHERE ds.software_class LIKE '%' AND ds.name ILIKE '%openssl%' ORDER BY ds.name ASC

The Software_Version column of the CSV can be used to narrow the scope down to OpenSSL 3.x – note that this query may also return packages that are not OpenSSL proper, e.g. libgnutls-openssl27, that have a version number starting with 3 but do not correspond to 3.0.x of OpenSSL per se.