w0ltage

SSH RCE via Race Condition (CVE-2024-6389)

4 min read

On July 1, Qualys researchers discovered a way to achieve remote code execution (RCE) in OpenSSH 8.5p1 through a race condition in the SIGALRM signal handler.

A race condition occurs when multiple parts of a program can change the same resource simultaneously, without any synchronization such as “I change value A first, then YOU do”

Interestingly, this vulnerability already existed in 2006 under CVE-2006-5051 and was patched in OpenSSH 4.4p1.

However, this vulnerability accidentally reappeared in production, leading Qualys to nickname it regreSSHion.

Dangerous Signal Handler

OpenSSH’s sshd configuration includes the option LoginGraceTime, which specifies the number of seconds a user has to authenticate before being disconnected, by default 120 seconds.

If a user takes longer than 120 seconds to authenticate, an asynchronous SIGALRM handler is triggered to interrupt the connection.

However, this handler interrupts synchronous functions that are not async-signal-safe, such as syslog().

Qualys found that during this race condition it is possible to corrupt the heap memory containing FILE structures and redirect program execution.

How syslog() feels every time exploitation is attempted

Heap Corruption

Memory management consists mainly of two concepts:

  • Stack: ordered memory
  • Heap: memory stored in an unordered manner

The first challenge for attackers is to arrange specific chunk layouts in the heap memory. This is achieved through prolonged exchange of valid and invalid certificates during key exchange authentication.

In the final heap layout, there should be a free 8KB chunk and a small free chunk of 320 bytes separated by “chunk barriers” that isolate free memory blocks.

Jumping to the server connection:

  1. The attacker exceeds the authentication time specified by LoginGraceTime.
  2. The asynchronous SIGALRM handler triggers a synchronous call to syslog().

Here attackers face another challenge — they need to intercept the execution of malloc() inside syslog() between lines 4327 and 4339 of the source code, when malloc() has allocated memory but not yet moved it.

This causes the available 8KB block to split into two 4KB chunks — one allocated, the other free leftover.

A strange situation arises: interrupting malloc() causes the free chunk to be linked to a free memory list, while the attacker still has access to this heap area.

Knowing this memory will be overwritten, the attacker artificially enlarges the free chunk size to cover the small 320-byte block prepared at the start of the attack.

Think the attack is over? Not quite.

All these heap manipulations must occur before the asynchronous SIGALRM handler calls async-unsafe synchronous functions: __tzfile_read() and fopen().

If everything aligns:

  1. fopen() allocates its FILE structure into the small 320-byte chunk.
  2. __fread_unlocked() overwrites the free 4KB block with a read buffer, corrupting part of the FILE structure allocated by fopen().

  1. The attacker, having control over the buffer, overwrites the corrupted FILE structure, eventually redirecting the program’s execution flow to execute arbitrary code.

That’s it — just a few operations back and forth, and the attacker gains root code execution.

Let’s summarize the attack with the diagram below:

How Serious Is It?

Besides requiring glibc on the system, processor architecture plays a big role.

For 32-bit systems

  • 3–4 hours to win the race condition out of ~10,000 attempts at 100 connections within 120-second windows.
  • 6–8 hours to find the correct address and successfully execute code as root once
    • thanks to ASLR (Address Space Layout Randomization), which randomizes the stack, heap, library code, and program memory, making it hard for attackers to locate.

For 64-bit systems

  • No confirmed successful exploits yet.
  • More addresses to guess (32-bit = 2322^{32}232 vs 64-bit = 2482^{48}248).
  • The most likely result is attacker frustration leading to ragequit.

If your appetite for such technical analyses is still not satisfied, read my simpler analysis of the infamous xz v5.6.0-1 backdoor.

Have questions on the vulnerability?
Read the Qualys vulnerability analysis.

Graph View

Backlinks