Podcast
Root Causes 253: OpenSSL Vulnerability Explained
Hosted by
Tim Callan
Chief Compliance Officer
Jason Soroko
Fellow
Original broadcast date
November 4, 2022
Last week the OpenSSL project announced an upcoming critical patch, leading to a great deal of speculation about this flaw and its implications for SSL certificates. We explain what the flaw was, what you should do, and why certificates are unaffected.
Podcast Transcript
Lightly edited for flow and brevity.
So, we want to talk about the OpenSSL flaw. So, a little bit of background. On Tuesday, October 25, there was an announcement from the OpenSSL Foundation Association, whatever that is – working group – that said that a critical patch was coming on the following Tuesday. Tuesday, November 1, and everybody should be prepared to deploy it right away. And this led to a lot of coverage and a lot of speculation about are my certificates going to be affected and we actually got contacted by a number of customers who wanted to know what’s gonna happen here with regards to my certificates. And there was no information and all we had to tell them was, well, we will find out when you find out. So, November 1 rolled around, the patch was deployed and we all learned that the flaw, the vulnerability, was a buffer overflow vulnerability and so, what are the implications of that, Jay?
Buffer overflows are something we’ve heard about so much in software through time because of the fact that, without getting into it too much, it potentially allows a malicious player with access to that compromised machine – the machine that has this vulnerability –the software that has a buffer overflow, the worst case scenario, Tim, is when the buffer overflow allows the attacker to do a remote code execution. And the reason I’m bringing this up very specifically is because remote code executions will get your vulnerability flagged as critical every single time. Imagine, this is software that is running on a web server and web servers by definition have some exposure to the hostile public internet and so therefore, the chance of a malicious player being able to somehow do something to a web server to then execute code of their choice, that absolutely is critical worst case scenario. That’s definitely something you don’t want to have happen to you. And therefore, it would require you to patch as soon as possible and then do other kind of security remediation measures. Sorry for the diatribe, Tim, I just want to get the thought out here to everybody just to make everybody understand why it was critical, listed as critical for a time and then went down to high and not critical. And the reason was because when the buffer overflow was first understood and discovered, the people that are part of this project had no means to be able to determine, hey, is a remote code execution possible here? Because they weren’t sure, they basically classified it as critical pending studies and then some really smart folks who understand these things said, hey, the four bytes of buffer overflow shift that are possible here taking a look at every single distribution of Linux and every single way to compile this code is there a way to make it possible for a remote code execution. It was determined, Tim, and that’s what was really just announced, is that the severity of the buffer overflow, the amount of bit shifts that were possible were not sufficient under any circumstance to be able to complete a remote code execution. With that study being done, that allowed the severity to be brought from critical down to high. So, that’s it in a nutshell, Tim.
It’s an unfortunate coincidence that the circumstances were such that people could look at this and see that critical severity and think, oh gee, is there a problem with my certificates? Because of where it occurred and you also understand why they said it where they said it because, if you can do remote code instant execution that’s really bad and so, all of those things occurred but at the end of the day, it turns out that the connection to digital certificates, the connection to SSL is nothing more than the coincidence of where in the code this particular overflow opportunity occurred and really nothing more than that.That’s an extremely important point, Tim. OpenSSL is just so ubiquitous. It’s so everywhere and, Tim, you and I talk about PKI and certificates and we talk about the generation of certificates. We talk about web servers all the time and OpenSSL is an open-source project that’s been around an awfully long time and has kind of been become the defacto. Not everywhere, but in so many places, that it’s really critical to keep an eye on problems with it. If you take a look at problems in the past with OpenSSL, they have been painful and they have affected things like certificates. They have affected so many systems that just the patching cycle was onerous. And in this case, it’s just a buffer overflow that occurs in such a way that, yes, we absolutely are saying to people go off and patch but you don’t have to be worried about compromised certificates.And so let’s just make that part unambiguously clear. Your existing certificates are fine. You do not need to replace them. You do not need to revoke them. They will not be revoked out from under you by your CA at least not for reasons of this particular vulnerability. If something else is wrong, obviously, that’s a different story. But this vulnerability doesn’t drive any action on your existing certificates. It also doesn’t drive any action on the certificates you may have ordered that have not been delivered yet and it also does not require you to change your process in any way for future certificates that you would order. It is not affecting that part of your environment. Now you should still do the patch. Do the patch because there is a flaw. There is an overflow flaw. So do the patch but don’t go and monkey with your certificates. Your certificates are just fine.Well said, Tim. Well said. Hey, can I throw in something now that we’ve got that behind us and that’s an important message. I do want to say, I don’t know exactly what the podcast number is but we were talking about the Rust programming language and the fact that there are equivalents to OpenSSL written in the Rust language. And the reason for that is to avoid, for overflow errors. So, I gotta say, there was a recent statement and by statement I mean there was a tweet by Mark Russsinovich over at Microsoft. Well-known software engineer developer and very respected especially in Azure and a lot of his internal tools for that Microsoft stack and technologies and he basically said something that I never thought I would see but there it was in black and white and he said, for those of you who are coding in C, C++, you really have to ask yourself why you are using it. There has to be a very, very good reason and if you don’t have a good reason, you really should be looking at memory safe languages like Rust. And so the message was hyper clear. We are dealing with legacy languages and their problems that lead to buffer overflows and the current state of affairs which is you can now develop without too much fear or any fear of buffer overflow errors. So, we are gonna be living in this world for a while and as long as we have OpenSSL, we will be living probably with this. It may not even be the last buffer overflow we hear about, Tim.
In fact, it’s such a common issue that we barely report on it anymore and I gotta tell you that the ways that the white hats do their fuzzing, which is a way of trying to tease out finding buffer overflow errors, these guys just get better and better and better every single day and they’ve been doing it for 20 years plus. So, it won’t be the last time we hear of it; however, for those of you who are developing it and especially those of you who are developing in cryptography, check out the Rust language. It’ll help you to avoid this problem.
Alright. I think that’s a great additional point. Short and sweet, but I think that’s all there is to it. We didn’t know if this was gonna be a big deal. We didn’t know if this was gonna be another Heartbleed or another Debian and it turned out not to be. So, that’s excellent. Very happy about that and go ahead and deploy the patch.Stay informed with expert insights
Subscribe to Root Causes for engaging discussions on PKI, digital security, and best practices for protecting your organization's critical assets. Don’t miss an episode!
