CVE-2008-4109: The Zombie Deadlock — When Logging Kills Your SSH Daemon

Imagine you are a bouncer at a club. Your job is to check IDs. You have a rule: if someone takes too long to find their ID (say, 120 seconds), you kick them out. But imagine that in the act of kicking them out, you decide to write a detailed log entry about it in a notebook. Now, imagine that while you are writing that entry, the universe freezes, duplicates you, and the duplicate you tries to write in the same notebook at the exact same time.

Neither of you can write. Neither of you can move. You are both frozen, holding the pen, staring at the page. Forever. That is effectively what happens in CVE-2008-4109.

This vulnerability is a classic case of "the fix was worse than the bug." In an attempt to patch a previous race condition (CVE-2006-5051), maintainers for Debian, Ubuntu, and SUSE inadvertently introduced a deadlock scenario. By trying to log a timeout event safely, they used functions that are inherently unsafe in that context. The result? A trivial Denial of Service that allows any attacker to turn your shiny sshd processes into an army of unmoving, zombie-like corpses that refuse to die and refuse to let anyone else in.

To understand this bug, you need to understand the Golden Rule of UNIX signal handlers: Touch Nothing.

When a signal (like SIGALRM) fires, the operating system interrupts the main process flow immediately. It doesn't care if the process was in the middle of a malloc(), a printf(), or a syslog() call. It pauses the main execution thread and jumps to the signal handler function.

Here is the catch: many standard library functions are not reentrant or async-signal-safe. Functions like syslog() often use global mutexes (locks) to ensure that log lines don't get jumbled together. If the main process grabs the lock to write a log, and then the signal handler fires before that lock is released, the handler runs.

If the handler also tries to call syslog() (which it did in this case), it tries to grab the same lock. But the lock is held by the main process, which is currently paused waiting for the handler to finish. The handler waits for the lock. The main process waits for the handler. It is a classic deadlock.

The Vulnerable Chain

1. Trigger: LoginGraceTime expires (default 120s).
2. Signal: SIGALRM is delivered.
3. Handler: grace_alarm_handler() is invoked.
4. Mistake: The handler calls sigdie(), which calls syslog().
5. Crash/Hang: If the interrupted code was already inside syslog, the process hangs forever.

Let's look at the logic flow that doomed these distributions. The issue wasn't in the core OpenSSH logic per se, but in how downstream patches modified the grace_alarm_handler.

The vulnerable code looked something like this (simplified for clarity):

// The signal handler triggered on timeout
void grace_alarm_handler(int sig)
{
    // ... various checks ...
    
    // THE BUG: Calling a logging function that isn't async-safe
    sigdie("Timeout before authentication for %s", user);
}
 
void sigdie(const char *fmt, ...)
{
    // internal buffer logic
    // ...
    // Calls syslog(), which uses internal mutexes
    syslog(LOG_INFO, "%s", buffer);
    _exit(1);
}

The sigdie function is a wrapper that eventually formats strings and sends them to the system logger. While convenient for debugging why users are getting disconnected, it is fatal in a signal handler.

The Deadlock Diagram

This Mermaid diagram illustrates exactly where the process freezes:

When this happens, the child process spawned to handle the incoming connection enters a permanent wait state. It never exits. It never releases its slot.

Exploiting this does not require shellcode, ROP chains, or heap feng shui. It just requires patience and a loop. The goal is to exhaust the MaxStartups limit (usually defaults to 10:30:100 or just 10 in older configs).

If we can freeze 10 child processes, the main sshd daemon stops accepting new connections. Game over.

The Attack Strategy

1. Connect: Open a TCP connection to port 22.
2. Wait: Do nothing. Do not send a version string. Do not authenticate.
3. Race: Hope that when the server times out (120s), the server is busy doing something that holds a lock (like logging a different event or handling memory).
4. Repeat: Open as many connections as allowed.

Realistically, hitting the race condition requires statistical probability. The server needs to be executing an unsafe function at the exact moment the timer fires. However, an attacker can bias the odds by forcing the server to log. For example, sending junk data that triggers verbose logging right before the timeout helps line up the syslog collision.

If successful, the sshd process list will fill up with <defunct> or stuck processes, and netstat will show connections in ESTABLISHED or CLOSE_WAIT that never die.

[!NOTE] Modern Context: While CVE-2008-4109 was a DoS, the exact same race condition in CVE-2024-6387 (regreSSHion) was proven to be exploitable for Remote Code Execution on glibc systems because the state of the heap is inconsistent during the signal handler execution.

The fix is philosophically simple: Don't do complex work in a signal handler.

If a user times out, just kill the process. Do not try to format a string. Do not try to tell syslog about it. Just _exit().

The Code Patch

The correct implementation for a signal handler in this context is to set a flag and let the main loop handle the exit, or use strictly async-safe functions.

// The Safe Way
void grace_alarm_handler(int sig)
{
    // Directly exit without cleaning up buffers or locking mutexes
    // _exit() is async-signal-safe. exit() is not.
    _exit(1);
}

Alternatively, if logging is absolutely required, it must be guarded to ensure it doesn't run if the signal interrupted a critical section. The upstream fix often involves #ifdef guards or replacing syslog calls with direct write() calls to file descriptors, which bypass the libc locking mechanisms.

Distributions released patches that removed the sigdie() call from the handler, effectively silencing the timeout log but saving the server from deadlock.