regreSSHion: The Return of the Signal Handler Nightmare

It’s not often we get to say 'I told you so' about a bug from 2006, but here we are. OpenSSH, the absolute bedrock of internet infrastructure, has tripped over its own shoelaces. Again.

Meet regreSSHion (CVE-2024-6387). It’s a signal handler race condition in sshd that allows unauthenticated remote code execution (RCE) with root privileges. If that sounds familiar, it's because this is effectively a regression of CVE-2006-5051. Someone, somewhere, refactored some code and accidentally invited an old ghost back into the machine.

Why should you care? Because sshd is exposed to the internet on millions of servers. It is the front door. And right now, the lock on that door has a microscopic fracture that, if hit with a sledgehammer 10,000 times at the exact right microsecond, causes the door to dissolve.

Here is the golden rule of Unix systems programming: Do not do complex things inside a signal handler.

When a signal (like SIGALRM) fires, the OS pauses whatever the CPU was doing to run the handler. If the main program was in the middle of a malloc() or free() call (manipulating the heap), and the signal handler also tries to allocate memory (via syslog()), you get a reentrancy problem. The heap metadata is in an inconsistent state. The handler corrupts it. Game over.

In sshd, there is a LoginGraceTime setting (default 120 seconds). If you don't log in by then, sshd gets impatient. It raises a SIGALRM. The handler for this signal, sigdie(), decides to be helpful and log a message via syslog().

[!WARNING] syslog() is NOT async-signal-safe. It uses malloc(). Calling it inside a signal handler is like trying to change a tire while the car is moving at 60mph.

Let's look at the crime scene. The vulnerability exists in the signal handler logic located in sshd.c.

Here is the simplified logic flow that dooms the process:

// The Signal Handler
void sigdie(int sig) {
    // ... various cleanup ...
    
    // THE BUG: calling syslog() inside a handler
    syslog(LOG_INFO, "Timeout before authentication for %s", client_addr);
    
    _exit(1);
}

When SIGALRM fires, execution jumps here. If the main thread was currently inside a glibc memory function (like malloc or free handling public key exchange data), syslog will try to grab the same heap lock or manipulate the same linked list pointers.

This results in heap corruption. The fix is simple but annoying: don't use syslog in the handler. Use a safe primitive or just _exit().

Exploiting this is not like a standard buffer overflow where you send a long string and win. This is a race condition. We are playing a probabilistic game against the scheduler.

The Strategy:

1. Connection Flood: We open exactly MaxStartups connections to the server.
2. Timing: We perform the SSH handshake but stall just before authentication.
3. The Trigger: We wait for LoginGraceTime (120s) to expire.
4. The Collision: We need the SIGALRM to interrupt the main thread precisely when it is manipulating the heap (e.g., parsing a massive public key packet we sent).

If we time it right, the heap state is corrupted. By carefully grooming the heap beforehand (Heap Feng Shui), we can turn this corruption into an overwrite of a glibc structure (like _IO_2_1_stdout_ or dtors).

From there, it's standard ROP (Return Oriented Programming) to bypass ASLR (Address Space Layout Randomization) and land a shell. Note: This takes on average ~10,000 attempts on a 32-bit system, and significantly more on 64-bit due to ASLR entropy. It's noisy, but it works.

If an attacker wins the race, they execute code as the user running sshd. In most default configurations, that user is root.

• Privilege Level: Root / System Administrator.
• Authentication: None required.
• Detection: High. The exploit requires thousands of connections, filling logs with "Timeout" errors—ironically, the very log message causing the crash is what alerts the SOC.

While the race is hard to win (taking hours or days), the payoff is total system compromise. This is a critical risk for high-value targets where an attacker can afford to be noisy.

First, check your version. OpenSSH versions 8.5p1 through 9.7p1 are vulnerable.

Immediate Fix: Upgrade to OpenSSH 9.8p1. The developers removed the unsafe syslog call from the signal handler.

Workaround (If you can't patch): Set LoginGraceTime to 0 in your sshd_config.

# /etc/ssh/sshd_config
LoginGraceTime 0

[!NOTE] This disables the timer entirely. This prevents the signal from ever firing, neutralizing the bug. However, it exposes you to a Denial of Service (DoS) where attackers use up all your connection slots by holding them open indefinitely. Pick your poison: RCE or DoS.