MalwareTech Posted November 5, 2022 Share Posted November 5, 2022 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. 18 4 Link to comment Share on other sites More sharing options...
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!Register a new account
Already have an account? Sign in here.Sign In Now