Don’t go into Depression because of RegreSSHion : CVE2024–6387
Hello everyone, today I’m going to try and explain the new CVE that was exposed earlier this month alongside the POC published on GitHub and why it was worth every minute spent researching it instead of kitesurfing in front of the most amazing sunsets I’ve ever seen.
First things First:
In order to understand the criticality of this CVE we need to understand how important of an issue an RCE vulnerability in ssh; A quick search of shodan shows that there are about 14 million exposed glibc-based Linux systems the wild, prone to this vulnerability which is effects openSSH versions lower than 4.4p1 or between 8.5p1 to 9.8p1.
The reason of the jump between the version is the exact reason the CVE is named “RegreSSHion” — The CVE is a regression of an older CVE that was patched in 2006 and then patched out accidentally in 2020 when someone unintentionally committed out the macro:
#ifdef DO_LOG_SAFE_IN_SIGHAND” from sigdie()
This commit generated the option to win a race condition which will let modify the heap in a way that can generate an arbitrary code execution with full privileges as it runs in the context of sshd (the openSSH process) in a privileged mode.
In addition, the function is triggered by a packet received, therefore it can be triggered remotely via connection verification.
To sum things up, this is a critical CVE that can let an attacker receive RCE with full privileges and it is the second vulnerability of this kind exposed in 2024 (after the XZ backdoor) — WHAT A YEAR and we are only half way through.
During the following article I will try to explain the exploit that the Qualys Security Advisory team found and did an excellent job in explaining with elaborate, in-depth low-level explanation in this article :
https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt
High-level Technical explanation of the CVE
During login attempt to the server, there is a timer and if the connection attempt takes more than “LoginGraceTime”, which by default is configured to 120 seconds, then a SIGALRM signal is called asynchronously.
If the call happens during a malloc when space is allocated but size is not yet determined (meaning, attackers win a race condition) the heap will be in an unconsistent state.
Finding the right race to win:
Attackers can craft a packet where the content is arbitrary and it overrides a FILE structure in the heap which has a function pointer in its header.
This capability is possible thanks to the function sigdie() in grace_alarm_handler() that calls a log function which mallocs a FILE handler and a read buffer from the input. Here is a screenshot of an inner function tz_read() that is being called from the do_log() function in sigdie():
Coincidentally, the name of the file is “RCE” ;)
Malloc()ing:
Now we need to understand the correct place to insert the heap into an unconsistent state.
Let’s look at the malloc function:
If the SIGALRM interrupts the malloc function running between lines 4337 to 4339 the heap will get to an unstable state where the chunk to be allocated already counts as free (linked to the unsorted list of free chunks) its size is yet undetermined. Meaning if we can override a couple of bytes more than the chunk allocated we can override the next part of the heap which will be a FILE structure. The 3rd byte of the File structure header will have a function pointer so we can override its content to point to a function of our own, meaning a shellcode that will run and execute a shell for us to run code remotely in the context of malloc!
To further understand the attack let’s look at the following illustration of the heap:
As we can see, the race condition lets us override the first 3 bytes of FILE so we can modify the function pointer to point to our shellcode; So instead of calling the wanted function of this header, it will call our shellcode.
Facing some obstacles in the wild
As is always is with exploiting RCEs — the real life is not as fun to work on as a testing environment. In the wild there are some defense mechanism that makes this attack hard to exploit:
1. Curving the right malloc patterns:
The method I’ve showed is a very simple example of the heap spraying. In the wild, the heap looks a bit different and the packet to send needs to be a bit more complicated in order for the attack to succeed
2. ASLR:
The whole exploit is built on the assumption that ASLR doesn’t exist and that we know where the f_ctor of the FILE will be.
This case is only true in the situation of i386 machines! For 64 bit machines the situation is different because of the ASLR but for i386, due to a bug, glibc is always mapped to either 0xb7400000 or 0xb7200000 and the 0xb74 is slightly likelier. This reduces the packets we have to bruteforce in order to win the race-condition by a lot and makes the attack feasible with in a few hours and not a few days to weeks
3. NX:
We assume NX is not enabled because in the version of i386 it really isn’t. This lets us focus on the exploit itself without thinking about where the shellcode is and the permissions of that specific segments permissions.
4. The time it takes to exploit successfully:
At the end, this attack is still a race condition attack, meaning there is a race that needs to be won in order to bring the heap to the unconsistent state it needs to be in, in order to modify the function pointer we want to modify. While adding the fact that we also need to win the incorrect “ASLR” in i386, the Qualys team calculated an average of ±10,000 packets sent in order to trigger the exploit. With a calculation of 120 seconds of a failed login attempt and 100 connections at a time (this is the maximum amount by default), this attack takes about ±3.33 hours to succeed for each glibc base address. We might need two tries for i386 meaning around ±3.33-±6.66 hours.
Conclusion:
Although there are defense mechanisms that make this vulnerability hard to be exploited on a lot of machines, there are still plenty of servers that are prone to this attack must be mitigated
High-level POC explanation
I looked into an open source POC of the exploit and it amazed me how such a simple c-code can make so much damage to the world.
A link to the POC on GitHub — https://github.com/xonoxitron/regreSSHion/blob/main/exploit.c
In my low-level technical report I elaborate on the details but here I just want to note one interesting fact about the POC:
In the code attached above, we see the part where there is an attempt to win the race condition. We can see that the fake packet is generated and sent without the last byte (the byte that is supposed to override the function pointer in the FILE structure). The final byte will only be sent 1ms before triggering the SIGALRM and this is because sending a big packet might make us lose the race because of network delays.
Patches and Mitigation
Sophisticated RCEs always have nice and easy mitigations and it’s a pity that they don’t become actions immediately. Some of the possible mitigations are:
1. Patching Open-SSH to version 9.8p1 or above
This is the best option. In general, it is always best to update to the most patched version of any software in order to not be prone to vulnerabilities and deprecated functions. One more option is to manually patch SSH to defend against this exploit. Elaboration is in my detailed low-tech technical report about this CVE
2. Not exposing SSH to the WWW
If you can limit the exposure of people connecting by SSH to your servers it is always good and there are plenty of software that can help defending your inner networks by limiting the allowed connections via SSH.
3. Patching Login Grace Time
Setting LoginGraceTime to *0* in the configuration file will eliminate the option to race condition. With that said, it does make it easier to DDOS the server. So don’t hurry up with this specific solution before trying out the other solutions.
4. Logging suspicious connections
In the low-level technical report, I elaborate on how a triggering packet of this exploit looks like. Therefore, a simple communication signature can be generated for a monitoring system of your network to detect and prevent a communication and behavior that looks like this exploit.
Special Thanks:
Further explanation of the technical details and mitigation options can be found in my low-level technical report about this CVE.
I want to thank the Qualys Security Advisory team for their outstanding research — attached again here.
I also want to thank xonoxitron for a well explained POC that help me understand the bits and bytes of the exploit- attached again here.
Last but not least, I want to thank you readers for reading, hope you enjoyed reading it as much as I enjoyed writing it!
