Tech Support
Documentation
Login
Contact Us
TuxCare BlogA Blast From The Past: RegreSSHion
by Joao Correia
July 12, 2024 - Technical Evangelist
It’s summer, and the year so far has been prodigious in high-stakes hacks impacting very high profile companies, like Ticketmaster or Change Healthcare, and sophisticated malicious operations like the one targeting the xz project. We can now add another very significant incident to the list, with the RegreSSHion (these names…) vulnerability hitting OpenSSH.
SSH is the de facto remote access tool of choice, is present on everything from servers to your television, and whenever flaws are discovered that impact it, the cybersecurity world starts to hyperventilate.
The Vulnerability
RegreSSHion, or CVE-2024-6387 if you’re not on a first name basis with it, is a vulnerability disclosed on July 1st of 2024. Security researchers found that the login process when connecting to the OpenSSH server (commonly sshd) has an exploitable behavior. Remotely exploitable, that is.
When a connection is initiated, and the client fails to complete the login process, there is a built-in timeout period (controlled by the LoginGraceTimeout setting, defaults to 120s in most installations), after which the connection is terminated. When sshd terminates the connection, it triggers a signal called SIGALRM asynchronously – meaning sshd does not hang while it’s processing – and several event handlers pick it up. These event handlers can be thought of as specific functions that clean up resources tied up by the now-defunct connection or writing to the logs that a connection attempt was performed but failed to complete. The actual vulnerability comes from the fact that these event handlers are not themselves coded in such a way as to be async-safe, and can produce unexpected behavior in very specific (and difficult to trigger) scenarios.
The Exploit
Exploiting the vulnerability requires a set of conditions to be present on the server. Unfortunately for many sysadmins and organizations, these are fairly common.
First, OpenSSH must be running a vulnerable version – but more on affected versions further ahead. Second, the system must run glibc, as the unsafe async functions come from there. Third, there must not be any form of mitigation in place; in this regard, the *BSD folks are feeling pretty good about their distribution choice right now, since it has included async-safe versions of the functions for a few decades now.
To trigger the vulnerability, an attacker has to attempt the login process and let it timeout, and repeat this process (potentially many attempts). The right functions have to run at the right moment, and, in an async environment affected by other processes on the system, this does not happen often. Triggering the flaw becomes a probabilistic rather than deterministic process. The security researchers behind the finding estimated that, for 32 bit systems, this could take, on average, between 8 hours to a day. On 64 bit systems, given the much larger address space, this could potentially take weeks.
When the right set of functions are executing at the right moment, however, a remote attacker can trick the system into running attacker-controlled code, like opening a shell – with root privileges.
The very long period of time that the exploit can take makes widespread exploitation of this vulnerability unlikely, but targeted attacks are definitely an option for malicious actors. It’s relevant to point out that the same security researchers that demonstrated this exploit went to great lengths to mention that they simply wanted to show that it could be exploited, and their code was in no way optimized – it’s very possible that sufficiently motivated threat actors can do just that and slash the exploit time.
My SSHD Is Not Exposed to the Internet
And that’s a great choice! Unfortunately, a quick Internet-wide scan found upwards of 14 million exposed SSH services. While not all have the right conditions for this attack to succeed, even a small portion is still a considerable number of systems that could be open for malicious business.
Keeping your critical services off the Internet, by binding them only to internal, not port-forwarded addresses, or by blocking them at the firewall level, is a good option. In fact, it shouldn’t take a vulnerability like this one to justify that option, but the more services it helps move away from potential attacks, from RegreSSHion or simple password spraying, the better.
I Have a Gray Beard and I Recall Something Similar…
And you have a great memory too. It turns out that RegreSSHion impacts versions of OpenSSH between 8.5p1 and 9.8p1 (no longer vulnerable), as the code responsible for the bug was committed in 2020.
BUT… it also impacts OpenSSH versions prior to 4.4p1, from 2006 (CVE-2006-5051). It turns out that, in 2006, this same bug had been found, and fixed. And then fixed again in 2008, because the first fix apparently wasn’t correct (CVE-2008-4109).
So how come it made it back into the codebase? Well, memory and time are not great partners. When the code was submitted in 2020, no one noticed that the same code commit would make OpenSSH again vulnerable to an already fixed problem. An “ifdef” was removed from the code, which was gatekeeping the code to protect from the earlier bug, and so it could be exploited again.
Dodging Bullets
Remotely exploitable vulnerabilities that result in privileged access are some of the most dangerous ones out there. When they impact software as widely used as OpenSSH, it’s a nightmare scenario. The silver lining to RegreSSHion is that it is very slow to trigger. This has made it significantly less dangerous than it could have otherwise been.
Just like with xz, where the backdoor was caught just at the right moment before spreading, we may have dodged another bullet with RegreSSHion due to its slow-to-exploit time.
Another significant dodged bullet is that the version shipped with CentOS 7 was, according to Redhat, not vulnerable. Since this vulnerability was announced just after CentOS 7’s end-of-life date, had it been vulnerable, it would not have received any vendor-supplied patches, which in turn would have made the thousands of CentOS 7 systems still running out there very exposed.
It’s a truism that you’re not going to be lucky all the time. Someday, like Neo waving his arms dodging the Matrix bullets, one is going to hit home. Take a moment to take stock of your infrastructure, and not just for ssh. Start blocking unnecessary services from Internet exposure and enforce VPN connections. It’s the basic stuff that is both easiest to handle, like timely patching and firewalling, and the vector easier to attack for threat actors.
And doing it today is better than tomorrow.
[A special note to the AlmaLinux team. They released updated OpenSSH packages to handle this flaw within hours of disclosure, and much earlier than upstream and other big names in this space. Kudos!]
[A second note: as is common with these high-profile named vulnerabilities, as more people look into them, subsequent flaws are identified. A related one has already been identified and disclosed as CVE-2024-6409]
