vulnerability research OpenSSL Vulnerability (CVE-2022-3602 & CVE-2022-3786)

[MalwareTech]

On October the 25th OpenSSL announced a major vulnerability would be patched in their November 1st Update. They rated it Critical, which is the highest severity possible. The alert sent the entire industry into a bit of a spin, with people thinking it'd be the next Heartbleed. I actually ended up staying up all night to monitor the situation. 

I made a blog post about it here: https://www.malwaretech.com/2022/11/everything-you-need-to-know-about-the-openssl-3-0-7-patch.html

Technical details

The TL;DR is it turns out it's a 4 byte stack overflow in the TLS certificate email address parsing. A 4 byte overflow would typically be very difficult to exploit, but given this is a stack overflow, it's near impossible. Most modern compilers put stack 'canaries' which are basically random values checked at certain points during execution. The canaries typically sit between (and separate) the part of the stack which stores local variables and the part which stores saved variable / return pointer. The idea is that if a stack overflow occurs, the canary will be overwritten before the return address or other important pointers are overwritten. Prior to returning, the stack guard will see the canary variable has changed and exit the program.

There is still some flexibility with stack overflows where you could potentially alter program behavior by overwriting neighboring local variables. In the case of this vulnerability, the 4 byte overflow only allows overwriting part of the next variable on the stack, which isn't initialized yet and any modifications will just get overwritten with real data.

On top of the difficulty of the actual binary exploitation, the vulnerability is in the TLS certificate parsing, which is typically only done by clients. In most normal scenarios, a client will validate the certificate chain prior to reaching the vulnerable code. Basically, the malicious TLS certificate would have to be signed by a legitimate CA, or the client will throw an error prior to even parsing the malicious certificate.

The take away

Overall, it's basically a bug that's extremely unlikely, potentially impossible to exploit. It is however a good exercise in determining real vs perceived risk with fast turnaround. Researchers & security vendors often inadvertently overhype bugs (no vulnerability is the same and on paper risk often differs from real-world exploitability). I've often had to be the one to reverse engineer patches, figure out the vulnerability, work out how likely exploitation is, then write a report, all within the same day of the patch release. Even on days when the bug is useless, it's still a great learning experience. Almost every vulnerability requires quickly understanding parts of a piece of software, protocol, or exploit technique. Sometimes it's as simple as changing a value, other days you find yourself having a way greater understanding of the Microsoft Remote Desktop protocol than you'd have ever wanted to.

[jubjub]

5 minutes ago, MalwareTech said:

other days you find yourself having a way greater understanding of the Microsoft Remote Desktop protocol than you'd have ever wanted to.

I don't envy you on that adventure. Writing a rdp client from scratch in Python while challenging did not sound fun 😂

[MalwareTech]

2 hours ago, jubjub said:

I don't envy you on that adventure. Writing a rdp client from scratch in Python while challenging did not sound fun 😂

ngl, it sucks. But I found an 0day for my troubles, so worth it in the end. 

[Zillionaire]

Thanks for the post. I feel more at ease now 🙂