Yesterday, the OpenSSL Project fully disclosed and provided a patch for CVE-2022-3602, which had initially been deemed Critical, due to it being believed to allow Remote Code Execution (RCE). At the time it was also believed to only affect version 3+ of the library, which would somewhat limit its impact on networks, with a lot of implementations still using the LTS 1.1.1 version.

With the awaited update dropping and the full details of the vulnerabilities being announced, we now see that it is indeed just version 3 and above that was affected, with the latest patched version being 3.0.7, and there being two vulnerabilities: CVE-2022-3602 and CVE-2022-3786. Both CVEs are related to an issue with X.509 certificate email address buffer overflows and the full advisory is available at https://www.openssl.org/news/secadv/20221101.txt

The biggest thing about this disclosure, which will have largely eased the collective panic within the industry – since the last Critical vulnerability in OpenSSL was the well remembered Heartbleed vulnerability – is that the original CVE-2022-3602 was downgraded to High, as the OpenSSL project stated that they no longer felt that the remote code execution would be considered likely in common situations and the new CVE-2022-3786 was rated High from the outset because there is not an expectation for exposure to remote code execution on any platforms.

Many in the industry will be wondering whether the panic was all worth it, and from some respects you could argue that if you’d put significant resources into preparing for patching a critical vulnerability, those resources would have been better spent. However, on the other hand, you could see this as a good practice run at how effective your response is to something like this; How long did it take to identify all possibly vulnerable assets? Were there issues in doing this? How could things be improved for next time? Certainly, at the end of the day, these are still vulnerabilities that ought to be patched – maybe not with the same urgency as if they were Critical, but work that needs to be scheduled in, and then ultimately checked to make sure that all vulnerable systems have indeed been patched.

How Nipper can help

Once the NIST NVD has been updated with an entry for the vulnerability and been populated with affected vendors and platforms, Nipper can be used to check if any supported devices are affected. First you will need to update the NVD files, then the Vulnerability Audits run from Nipper will include checks for this OpenSSL vulnerability.

Updating NVDs in Nipper

The National Vulnerability Database (NVD) files stored with Nipper are updated with each new release of Nipper, but you can add the OpenSSL latest NVD file manually now, through Nipper’s Resource Manager.

For step-by-step instructions, see our guide on updating NVD resourcing in Nipper

Updating your Cisco PSIRT resources in Nipper

You can also update Nipper with an up-to-date PSIRT resource file within the Resource Manager. Our Cisco PSIRT update guide provides instructions for creating an API account, retrieving the resources and updating them in Nipper.

Visit the Support section of the Titania website for further guidance or contact the team at support@titania.com.

Not yet using Nipper to manage your network risks? Request a free trial now to begin discovering and identifying exact fixes for vulnerabilities in your firewalls, switches and routers.

Ed Bentley