OpenSSL Patches Punycode Vulnerability in OpenSSL 3.0
Today, OpenSSL released OpenSSL 3.0.7. This version patches a buffer overrun vulnerability that can be triggered in X.509 certificate verification. To exploit the vulnerability, the attacker would need to obtain a valid signature from a trusted certificate authority for a malicious certificate. The vulnerability is triggered by a malformed Punycode encoded domain name either in a hostname or the domain part of an email address included in the certificate. Exploitation will result in a crash (denial of service) or could also lead to remote code execution. OpenSSL initially rated the vulnerability as "Critical" but now downgraded it to "High."
Looks "not bad." Exploitation seems to be unlikely given the requirement for a valid signature from a trusted certificate authority. The remote code execution is only likely for a malformed Punycode email address. Patch this one as updated packages become available, but you can stand down from "Heartbleed status."
OpenSSL released two patches that were originally deemed critical. It appears that during the internal disclosure process, many of the operating system vendors have responded with comments and potentially PoC code that identifies many of the memory protections and compiler protections that would make reaching this bug for true exploitability harder than thought (potentially impossible, although that’s an absolute that I would never claim). There is, however, a chance that OpenSSL 3.0 is in use in Network gear such as firewalls, VPNs, switches, and routers. Most of these devices do NOT offer memory protections as they can’t afford to spend the computational cost of doing so. The only saving grace(s) is that the vendor may not have moved to OpenSSL 3.0 yet, and the customers may not have upgraded to software with the vulnerability. The only true way to tell is to wait for vendor disclosures. On a lark, I went ahead and looked at the latest Cisco ASA 9.18 version’s disclosure documentation (https://www.cisco.com/c/dam/en_us/about/doing_business/open_source/docs/ASA-9181-1650467697.pdf), and it appears that they are still disclosing 0.9 train and 1.1.X trains in that document. Please do not take this as an assured fact. Every vendor will have to perform this library search. If you are looking at your own servers, there will be scanners for this it’s probably just too early to tell.
For most organizations, I recommend taking a step back from the gritty details and ensure you have an inventory of where you leverage OpenSSL and what versions. For OpenSSL 3.x solutions, see where and how to apply the patch. Then you can focus on understanding the implementation of the solutions using OpenSSL 3.x that cannot be patched yet and see if there is a possibility of those implementations being exploitable. I posted the most useful resources I found thus far here: https://twitter.com/jorgeorchilles/status/1587482470131408898