[0:03] Hi, I’m Neatsun Ziv, CEO and one of the co-founders of OX Security, and today we’re going to talk about “regression,” not a software regression, but the CVE that was published yesterday. With me I’ve got Ronen, one of our researchers. Ronen, why don’t you introduce yourself? [0:24] Hi everyone, my name is Ronen,...
[0:03] Hi, I’m Neatsun Ziv, CEO and one of the co-founders of OX Security, and today we’re going to talk about “regression,” not a software regression, but the CVE that was published yesterday. With me I’ve got Ronen, one of our researchers. Ronen, why don’t you introduce yourself?
[0:24] Hi everyone, my name is Ronen, I’m a security researcher at OX Security.
[0:32] Okay, first of all, can you give us a short description, what are we talking about?
[0:37] We are talking about a vulnerability in OpenSSH, which is a prominent component of the Linux operating system. The vulnerability itself is RCE, remote code execution, meaning an attacker could potentially run and execute commands on the affected machine.
[1:05] Okay, so RCE, we’ve seen them before. How popular is this specific case?
[1:11] We’re talking about Linux, basically the operating system that runs the internet, so millions and millions of potentially vulnerable machines. And the vulnerability itself can be triggered from the network, so the potential damage is enormous.
[1:33] So how dangerous is it, beside being popular, because I’ve seen some numbers saying it’s affecting like 14 million exposed hosts. How dangerous is this situation?
[1:45] First of all, let’s talk about the CVE itself. It got a rating of 8.1, which means high, not critical. On the surface it looks like a big deal, but when you start to look at the details, and if you read the write-up from the Qualys research team, a great write-up, definitely credit to them, the details tell you a lot about the severity and the risk you might have with this vulnerability.
[2:25] I think the next question of course is, we know of a few cases like this in different variations, but how hard is it to actually exploit, beside theoretical?
[2:37] The nature of the vulnerability is a race condition. We’re not talking about Heartbleed, which was send a request and get information disclosure; a race condition means you need to work hard for this to work. Going back to the technical write-up, the team attempted and succeeded to exploit it in lab conditions, because they need to time the request very closely. The best they could do on old 32-bit Linux operating systems was after 10,000 attempts, which took them around six to eight hours to get an exploitation, meaning six to eight hours with 100 open connections to a machine until they managed to get some sort of exploitation.
[3:39] Before we get into more details, I really like the name, “regreSSHion,” but I think there’s an interesting story besides you saying it’s a regression. What’s the story behind that name?
[3:50] It seems that this bug existed already and was reported and fixed nearly 20 years ago. Back then nobody managed to exploit it to cause remote execution, but it’s really the same problem, the same race condition. Then around 2020, the bug came back; someone decided to use the vulnerable function again, and basically all the Linux operating systems from that period are vulnerable to this bug.
[4:44] So we’re talking about something from history, and it brings up the question of 32-bit versus 64-bit. I’ve seen a lot of questions saying, if I have 64-bit, am I vulnerable? Let’s start by explaining the difference in this case.
[5:00] Modern operating systems, and Linux is a modern operating system, have a lot of protection mechanisms against exploitation, and one of those is ASLR, basically randomizing the memory address space. A 32-bit operating system has an address space of four gigabytes; if you compare that to 64-bit, which is two to the power of 64, an enormous memory space, it’s really hard to exploit. So it will take time to exploit a 64-bit operating system, if at all.
[5:49] Okay, so if we’re talking about 32-bit, and you said it takes somewhere between six and eight hours, why does it take so long?
[5:53] Again, it’s a race condition; you need to time exactly the two requests that trigger the inconsistency in memory, and that’s a hard thing to do. This was done in a lab, where they controlled the jitter, the network connection quality, and they had to time it very closely. Plus, the vulnerable function is a bit different with each flavor of Linux, so they need a different payload and need to understand exactly which version of operating system they’re talking about. So it’s really hard to orchestrate that kind of attack; it’s hard in the lab, and think about the internet, which you cannot really control.
[6:58] Just to understand, so you’re saying you need to open like a hundred different requests at the same time, continue doing this, and hopefully the timeout will be exactly at the same second that you cause this race condition, and it just takes a lot of attempts until you nail the exact timing?
[7:12] Exactly, it’s statistical. You can open just one connection, but then it will take you years; so you need many attempts.
[7:23] Okay, so are there any known workarounds we can apply?
[7:28] Yes. Practically, the vulnerability is triggered by a timeout in the login session, meaning the attacker opens a connection to the SSH server and then doesn’t log in, which triggers the vulnerable function within the OpenSSH implementation. So you could reduce that timeout toward zero; by default it’s 120 seconds. This was tested, and you can basically reduce the risk of code execution; you might stay with a denial of service, but that’s definitely better than RCE.
[8:23] Can we limit the 10 or 100 connections to a lower number?
[8:30] Yes, that’s totally doable; you can do that in the SSH configuration file and limit the number of connections.
[8:40] The Qualys folks said they have a PoC exploit code they’re going to release in the future, but we’ve already seen some PoC code out there.
[8:51] The first thing that popped into my mind is, I wonder if it’s a bad actor that published this, because this is not an easy exploit to do. If you look at the GitHub repository it was published on, it’s not really a popular account, so I would be very worried. As security professionals, we should be aware of such things; I wouldn’t run any type of code on my computer unless I’m really controlling the environment.
[9:41] A few questions before we wrap up. Let’s say I do have remote code execution running as part of my OpenSSH, what does it mean, what permissions can I get?
[9:50] You are running at the highest privileges, meaning you can do whatever you like on that machine. Think about running code execution that creates a remote or reverse shell, and then you log in to that computer again without passing authentication; you can do whatever you want, create persistency, download more malware.
[10:18] Can I terminate running agents on the machine if I’ve got some kind of runtime protection?
[10:21] Yes, definitely.
[10:25] So just to conclude, what’s your prediction, will we see this one in the wild, or is it just a theoretical one, good practice but in reality not going to do any real damage?
[10:38] That’s a good question, it’s hard to tell. Someone might be able to, maybe the Qualys team would be able to create a more robust exploitation method, but it seems it still lies in the realm of a race condition, and exploitation would still be very hard to achieve.
[11:02] So guys, if you’ve got 32-bit machines connected directly to the internet, exposing OpenSSH directly to the internet, with no logging whatsoever, so somebody can just open 100 connections and it will go unnoticed, and of course no active security countermeasure?
[11:24] Definitely, that’s time to get busy and start patching.
[11:28] Luckily released on Monday, which is a good time to start the week with a fresh vulnerability. And thank you for doing it on the week of the 4th. So guys, thank you very much; if there are any more updates we’ll keep posting and updating. Please contact us if you’ve got any questions, we’ll try to assist as much as we can. Thank you very much.
