Initial Report
On October 27th it was reported by Dark Reading that organizations have five days to get ready for what the OpenSSL Project defined as a “serious” vulnerability impacting versions 3.0 and up of the widely used cryptographic library for encrypting digital communications. They caution that enterprises would rush to remedy the problem as soon as possible if this vulnerability turns out to be another Heartbleed flaw, which was the most recent serious vulnerability to affect OpenSSL.
Favorable News
We now have some good news after five days since the initial revelations of an internet-reshaping major flaw in OpenSSL. Instead of the critical rating that initially alarmed the online community, CVE-2022-37786 and CVE-2022-3602 have been published as high-rated vulnerabilities. According to OpenSSL:
“A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. 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. An attacker can craft a malicious email address to overflow four attacker-controlled bytes on the stack. This buffer overflow could result in a crash (causing a denial of service) or potentially remote code execution.”
As a result, the vulnerability is considerably harder to exploit than what was initially suggested.
Remediation
The two CVE reports published on November 1st indicate this issue as being present in OpenSSL versions 3.0.0 to 3.0.6. Despite the fact that these flaws are not as severe as anticipated, it is still advised that all businesses identify their OpenSSL implementations and update to version 3.0.7 right away. At this point, according to OpenSSL, there is no evidence that this vulnerability has been exploited in the wild and no operational exploit that could result in code execution. A list of notable operating systems and application runtimes which are packaged with a vulnerable version of OpenSSL has been established by the Computer Emergency Response Team (CERT) for the Netherlands.
What Now?
nGuard is ready to assist clients in detecting and mitigating OpenSSL vulnerabilities. nGuard can identify whether or not a vulnerable version of OpenSSL is present in your environment by performing vulnerability scans and penetration testing against both external and internal facing services. Organizations may feel at ease knowing that OpenSSL versions that are insecure are being fixed in their environments by carrying out these scans on a frequent basis.