Experts warn of critical security vulnerability discovered in OpenSSL

Understand what steps your organization needs to take now to prepare for the upcoming patch to address OpenSSL’s critical security vulnerability on November 1.

Security experts are giving organizations advance disclosure of a critical vulnerability discovered in OpenSSL version 3.0 and above, leaving many to speculate about the potential impact to their organization. 

The OpenSSL project team intends to issue a patch on Tuesday, November 1, for upstream OpenSSL. Such advance knowledge is unique in that it gives teams an opportunity to identify which of their applications are vulnerable before a patch becomes available, but it is also a double-edged sword: It gives bad actors the opportunity to develop targeted ways to attack potential weaknesses in the code before a patch is available. One key element of traditional responsible disclosure processes is that everyone should be on an equal footing, and vulnerability disclosures occur only after patches are created, validated, and made available. 

Since we’re still waiting on official patches to be issued, there is increased risk that bad actors could prey on teams scrambling for a patch by posting bogus versions with malware embedded within them. Organizations need to work swiftly but be vigilant to avoid falling victim to spoofed versions. For organizations accustomed to commercial patch processes in which there is a single authoritative vendor, this risk is heightened given how many forks, or branches, of OpenSSL exist. There are also many distribution channels for OpenSSL.

What can incident response teams do right now to prepare for the upcoming patch and changes in the threat landscape?

Know what’s in your code

Response teams should perform an analysis of all their software using a software composition analysis (SCA) tool. This includes all software they create, acquire, download, or consume, independent of origin or function (this includes commercial and open source software). If access to the source code of an application isn’t possible, a binary SCA tool should be used on the application and its libraries. The output of this analysis will show where OpenSSL is used, which version is in use, and where the origin point for that version is. The origin points for applications containing a vulnerable version of OpenSSL will vary, but that’s where the patches need to come from. It’s important to note that some origin points might not respond as quickly as others. This is an example of why vulnerability disclosures are typically embargoed.

Prepare to mitigate and patch

Operationally, organizations need to be ready to respond immediately when the provider of their specific OpenSSL components issue a patch. Ideally, this will be on Tuesday, but given that this disclosure is outside of normal embargo processes, it might be even earlier. With echoes of Heartbleed—the infamous OpenSSL vulnerability from April 2014—organizations may be time-pressed to fix the issue. They should err on the side of caution and take an all-hands-on-deck approach to finding what’s vulnerable and be ready to fix it when the patch is released. 

This is a developing story. New blog posts will be published when BDSA and CVE information is available with specific fixes for this vulnerability.

Stay updated on the latest information on the OpenSSL vulnerability

Subscribe to the blog