OpenSSL Heap Memory Corruption Vulnerability Fixed
Ever since Heartbleed made life miserable for anyone using OpenSSL, I get a sick feeling in my tummy whenever I hear about an OpenSSL security hole. The latest, CVE-2022-2274, didn’t reach Heartbleed levels of ick, but it was more than bad enough.
What happened was that the OpenSSL 3.0.4 release introduced a serious RSA bug in X86-64 CPUs supporting the AVX512 IFMA instructions. This set of CPU single instruction, multiple data (SIMD) instructions for floating-point operations per second (FLOPS) was introduced in 2018. You’ll find it in pretty much every serious Intel processor, from Skylake to AMD’s forthcoming Zen 4. In other words, it’s probably in every server you’re currently running.
Is that great news or what?
Memory Corruption
The problem is that RSA 2048-bit private key implementations fail on this chip architecture. Adding insult to injury, memory corruption results during the computation. The last straw? An attacker can use this memory corruption to trigger a remote code execution (RCE) on the machine.
Exploiting it might not be easy, but it is doable. And, even if an attack isn’t that reliable, if it’s used to hit a server that constantly respawns, say a web server, it will eventually make it through. Besides, simply burying a server with RSA 2048 OpenSSL requests would still cause a Denial of Service (DoS) attack.
It’s bad news any way you want to look at it.
High Score
It’s no wonder that NIST’s National Vulnerability Database (NVD) gave it a Common Vulnerability Scoring System (CVSS) score of 9.8. In case you’ve forgotten, that’s well into the Critical Level, or as I like to call it, pull the plug and patch it now level!
Now, if you properly test OpenSSL 3.0.4, it would fail, and you see the trouble before deploying it. Hands up, who tests OpenSSL after patching it? Right? And who moves on to your next system administration test without looking back? Yeah, that’s what I thought. Not enough of us.
Some did. For example, software resilience engineer, Alex Gaynor, spotted the problem and strongly recommended that a new release be made as quickly as possible. From his expert viewpoint, he thought “this issue qualifies as a CRITICAL within OpenSSL‘s vulnerability severity policy, and it makes it effectively impossible for users to upgrade to 3.0.4 to obtain its security fixes.”
He, and others like him, won their point.
The problem was fixed in OpenSSL 3.0.5. If you’re still using OpenSSL 1.1.1 or 1.0.2, good news. You’re not affected by this vulnerability.
