The OpenSSL project recently announced that it would release a new version of OpenSSL (version 3.0.7) on Tuesday, November 1. According to the announcement, the highest severity of the issue fixed in this release is CRITICAL. OpenSSL’s risk classification identifies critical vulnerabilities in OpenSSL as those affecting common configurations and likely to be exploited. In fact, it was just the second time the OpenSSL Project has addressed a flaw classified as “critical” (the first was for 2014’s Heartbleed Bug).
The GlobalDots engineers closely monitored the situation before the patch release to aid in the remediation process. They ensured our large customer base was up-to-date and protected – focusing on Akamai and Cloudflare CDN & Multi CDN users who were not affected. Also, by leveraging our partnership with Lacework, we optimized our customers’ IT & security teams’ cloud security posture in the wake of the patch release, ensuring their safety.
How One AI-Driven Media Platform Cut EBS Costs for AWS ASGs by 48%
OpenSSL addresses important vulnerabilities that can result into a DDoS
On Tuesday, OpenSSL released a new version to address two high-severity vulnerabilities – CVE-2022-3602 and CVE-2022-3786. The original heads-up from the OpenSSL project was that this issue would be critical, at the highest possible rating. Upon review with several organizations, the project has downgraded the matter to a high-level severity.
In this blog post about the issue, The project explains the reasons for such downgrading. The good news is that testing demonstrated the likelihood of remote code execution was much lower than initially expected, therefore justifying downgrading the vulnerability. Nevertheless, both reported issues can cause a buffer overflow which might result in a system crash, potentially resulting in a denial of service attack (DDoS).
What is OpenSSL?
OpenSSL is an open-source cryptography library widely used by applications, operating systems, and websites to secure communications over the internet using SSL (Secure Sockets Layer) and TLS (Transport Layer Security). OpenSSL has been around since 2012, with version 3 released in September 2021. It is one of the most widely used open-source libraries worldwide.
What’s at stake?
The OpenSSL change log has specific details, but both vulnerabilities are similar. Both occur when OpenSSL validates X.509 certificates.
When creating a secure connection between systems, these certificates help identify the systems and exchange the keys used to secure the connection.
To better understand it, let’s say this system is quite complex, but certificates are verified using a chain of trust, in the simplest terms. A known and trusted third party says, “Yes, certificate ‘A’ is, in fact, Alice’s certificate. And certificate ‘B’ is Bob’s.”
However, these vulnerabilities can occur during this validation process. If an attacker uses a maliciously crafted email address, a bug in OpenSSL 3.0.0—3.0.6 will fail to process it correctly. Such a mistake could lead to a buffer overflow, such as writing to memory, although the program shouldn’t.
For CVE-2022-3602, the result is that attackers can write whatever they want to 4 bytes of memory on your system. If anything, that will most often result in a crash. Moreover, there is an external chance that it could allow attackers to run their code on your system (remote code execution). However, that’s highly unlikely; therefore, the OpenSSL project downgraded the severity rating.
As for CVE-2022-3786, the attacker can force the system to write an arbitrary amount of bytes in memory by reading that malicious email address in the certificate. In that case, the attacker does not control what is written to memory, resulting most likely in a system crash.
How widespread is this vulnerability?
It has been confirmed that this vulnerability affects OpenSSL version 3.0.0 through 3.0.6, while earlier versions are not impacted.
What should and can be done now?
The first step is to verify the inventory of any systems in your environment that are running an impacted version of OpenSSL. With that list in hand, you can evaluate the impact of patching those systems to OpenSSL version 3.0.7.
Nevertheless, one challenge is that the attack vector is through X.509 certificates. Therefore, it’s implausible that any security control could mitigate the issue. Nonetheless, increasing the sensitivity of your monitoring practice while you work to patch impacted systems can be very handy.
Sometimes, you may consider disabling TLS client authentication until you can apply the update. Whether this is right for your environment depends on your threat model and risk strategy. GlobalDots, a worldwide trusted cyber security partner, can assist you with a comprehensive assessment, and monitor any further developments on your behalf. Contact our support immediately to get in touch, or start your tailor-made, optimized web protection scheme by requesting a demo.
