Executive Summary

On November 1, 2022, OpenSSL released a security advisory describing two high severity vulnerabilities within the OpenSSL library (CVE-2022-3786 and CVE-2022-3602). OpenSSL versions from 3.0.0 - 3.0.6 are vulnerable, with 3.0.7 containing the patch for both vulnerabilities. OpenSSL 1.1.1 and 1.0.2 are not affected by this issue.

In the days leading up to the security advisory, many were saying these vulnerabilities had the potential to be as bad as the Heartbleed vulnerability, and even OpenSSL originally stated that CVE-2022-3602 was going to be rated critical. Several factors seem to indicate that these vulnerabilities will not be easy to exploit and pose much less risk than originally thought:

• Both vulnerabilities require a malicious X.509 certificate that has been signed by a valid certificate authority (CA).
• A vulnerable server/client must parse client-side/server-side X.509 certificates to be affected by either of the CVEs.
• OpenSSL 3.0.0 was released in September 2021 and is much less widely used than OpenSSL 1.x.x, limiting the attack surface significantly as compared to Heartbleed. Based on data from the attack surface management tool Cortex Xpanse, we estimate the number of internet-facing OpenSSL 3.x installs to be less than 1% of the total OpenSSL installs.
• CVE-2022-3786 only allows bytes containing the character “.” (decimal 46) to be entered on the stack. Therefore an attacker has no ability to control the payload even though they can gain an arbitrary length overflow. This results in a denial of service (DoS) but not remote code execution.
• CVE-2022-3602 does allow for an attacker to gain a 4-byte overflow. However, default compiler settings of the OpenSSL project enable stack cookies and – outside of some edge case scenarios – the 4-byte overflow will overwrite the stack cookie and crash the program on Windows.
  • Even without stack cookies enabled, successful exploitation will be highly dependent on the stack layout, which can change with compiler types and selected compiler options.
  • On Linux there appears to be padding of a seed variable before the stack cookie and the 4-byte overflow overwrites this uninitialized variable instead of the stack cookie, and it does not crash the program.

Palo Alto Networks recommends customers apply the latest patch, because both vulnerabilities have been shown to cause a denial of service at the very least. There is publicly available proof-of-concept code that will enable anyone who manages to create a malicious certificate and successfully sign it, to crash unpatched servers.

OpenSSL is also distributed as source code, so compiler options are completely up to the end user, who may opt out of modern memory mitigations such as stack cookies, ASLR, DEP/NX, etc. Such decisions would make exploitation easier and raise the risk of remote code execution for CVE-2022-3786.

Palo Alto Networks customers receive protections from and mitigations for CVE-2022-3786 and CVE-2022-3602 in a variety of ways, including the following:

• Next-Generation Firewalls and Prisma Access with an Advanced Threat Prevention security subscription can automatically block related sessions.
• A Cortex XSOAR playboook can help automate remediation.
• Cortex XDR customers receive protections against remote code execution memory corruption exploits.
• XQL queries provided below can be used with Cortex XDR to help track attempts to exploit these CVEs.
• Cortex Xpanse customers can identify impacted versions through its “Insecure OpenSSL” policy.
• Prisma Cloud customers can identify vulnerable resources under the vulnerabilities tab.

Table of Contents

Details of the Vulnerability
Current Scope of the Attack
Interim Guidance
Conclusion
Palo Alto Networks Product Protections for OpenSSL Vulnerabilities
Next-Generation Firewalls and Prisma Access With Advanced Threat Prevention
Cortex XSOAR Automated OpenSSL Vulnerability Management
Cortex XDR
Unit 42 Managed Threat Hunting Queries
Cortex Xpanse
Prisma Cloud Vulnerability Management

Details of the Vulnerability

As described by OpenSSL in a security advisory, both vulnerabilities (CVE-2022-3786 and CVE-2022-3602) are “triggered through X.509 certificate verification, specifically name constraint checking.” They also note that this occurs after certificate chain signature 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.

Both vulnerabilities occur within the ossl_punycode_decode function of the OpenSSL library.

Both vulnerabilities require the following to successfully exploit:

• A malicious X.509 certificate that is signed by a valid CA
• A vulnerable server that is parsing the client-side TLS certificate

The malicious certificate will have a subjectAltName that specifies the otherName field with an SmtpUTF8 email address. The certificate will also have a namedConstraint field with an email address that includes punycode. These two certificate items combined allow the parsed certificate data to reach the ossl_punycode_decode function within the OpenSSL library. The namedConstraint field will contain the payload that is decoded to a 513 byte overflow.

The vulnerability described in CVE-2022-3786 allows an attacker to achieve a stack overflow of arbitrary length, which is limited to the “.” character (decimal 46), by crafting a malicious email address within the attacker-controlled certificate as described above.

The vulnerability described in CVE-2022-3602 is an off-by-one vulnerability that allows an attacker to obtain a 4-byte overflow on the stack by crafting a malicious email address within the attacker-controlled certificate as described above. On Windows systems the overflow will either result in a crash (most likely scenario) or a potential remote code execution (much less likely).

OpenSSL distributes the OpenSSL library with stack cookies enabled by default. Testing of CVE-2022-3602 by OpenSSL and external researchers has shown the 4-byte overflow will overwrite the stack cookie resulting in a crash. However, OpenSSL is distributed as source and therefore compiler options are completely up to the end user, who may opt out of modern memory mitigations such as stack cookies, ASLR, DEP/NX, etc. Such decisions would make exploitation easier and raise the risk of remote code execution for CVE-2022-3786.

On Linux systems, research has shown there is an uninitialized seed value on the stack just before the stack cookie. This uninitialized seed value on Linux systems gets overwritten and no ill effects have been witnessed. This vulnerability received quite a bit of attention in the week leading up to the security advisory, and several excellent blogs describe it in detail (in particular, posts from Datadog Security Labs and Colm MacCarthaigh).

Current Scope of the Attack

There are no known instances of exploitation of either of these vulnerabilities. Proof of concept code does exist that results in crashing of the process. Assuming an attacker is able to craft a certificate signed by a valid CA, denial of service attacks would be possible.

Interim Guidance

Update to the most recent version of OpenSSL as soon as possible. OpenSSL also recommends that organizations operating TLS servers should consider disabling TLS Client Authentication if it is being used, until patches are applied.

Conclusion

OpenSSL’s latest security bulletin describes two memory corruption vulnerabilities that initially were thought to be critical and potentially as bad as the Heartbleed vulnerability (at least in the case of CVE-2022-3602). Ultimately both were rated high risk and deemed not likely to result in remote code execution.

Based on OpenSSL’s blog post on the issue, they and several external researchers (Datadog, Colm MacCarthaigh and unnamed researchers who assisted OpenSSL during their investigation), have done extensive research that supports this conclusion. Although this was probably the best outcome we could have hoped for on such a widely used library, Palo Alto Networks still recommends customers apply the latest patch. Both vulnerabilities have been shown to cause a denial of service at the very least. There is also at least one publicly available proof of concept that will enable anyone who manages to create a malicious certificate, and successfully sign it, to crash unpatched servers.

Palo Alto Networks Product Protections for OpenSSL Vulnerabilities

Palo Alto Networks customers can leverage a variety of product protections and updates to identify and defend against this threat.

If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

• North America Toll-Free: 866.486.4842 (866.4.UNIT42)
• EMEA: +31.20.299.3130
• APAC: +65.6983.8730
• Japan: +81.50.1790.0200

Next-Generation Firewalls and Prisma Access With Advanced Threat Prevention

Both Next-Generation Firewalls (PA-Series, VM-Series and CN-Series) and Prisma Access with an Advanced Threat Prevention security subscription can automatically block sessions related to CVE-2022-3602 using Threat ID 93212 (Application and Threat content update 8638).

Cortex XSOAR Automated OpenSSL Vulnerability Management

The related Cortex XSOAR automation playbook can help you:

• Automate incident data enrichment
  • Tag CVE indicators
  • Link indicators to incidents in your environment
• Automate endpoint hunting
  • Hunt for Windows OS and/or Linux OS endpoints and retrieve OS endpoint IDs
  • Hunt for active processes running OpenSSL 3.x running in the above mentioned OS environments, Azure Sentinel logs and/or Splunk
• Take remediation action
  • Download the latest version of OpenSSL
  • Install the latest version of OpenSSL across relevant endpoints
• Notify analysts
  • Send analysts a notification if further investigations are needed

This playbook is part of the Rapid Response Pack, which includes various playbooks for trending vulnerabilities and threats. This content pack will be available in the Cortex Marketplace.

Cortex XDR

Cortex XDR customers receive protections against remote code execution memory corruption exploits (including those that may be possible in relation to these vulnerabilities) through its multi-layered security approach.

Cortex XDR customers can also make use of the XQL queries suggested by the Managed Threat Hunting team in the section below to search for signs of exploitation.

Unit 42 Managed Threat Hunting Queries

The Unit 42 Managed Threat Hunting team continues to track any attempts to exploit these CVEs across our customers, using Cortex XDR and the XQL queries below.

Host Insights indexes endpoint host files with the Search and Destroy feature, enabling analysts to sweep across endpoints in near-real time to rapidly locate files, such as vulnerable OpenSSL software.

Cortex XDR Pro endpoint customers without Host Insights can search for the presence of OpenSSL using the following query:

Cortex XDR customers with Unit 42 managed services subscriptions, including Unit 42 Managed Threat Hunting and Unit 42 Managed Detection and Response, automatically received a Threat Impact Report with technical details and guidance.

Cortex Xpanse

Cortex Xpanse customers can identify impacted versions through its “Insecure OpenSSL” policy.

Prisma Cloud Vulnerability Management

If you are using Prisma Cloud, you can detect affected resources under the Vulnerabilities tab. The scan automatically detects and alerts on vulnerable entities with the vulnerable OpenSSL package.

You can also search for CVE-2022-3786 and CVE-2022-3602 through the Vulnerability Explorer to list the affected resources in your environment.