> ## Documentation Index
> Fetch the complete documentation index at: https://help.onetsolutions.net/llms.txt
> Use this file to discover all available pages before exploring further.

# RegreSSHion (CVE-2024-6387): Unauthenticated RCE in OpenSSH

> A regression of a 2006 OpenSSH bug reappears in recent versions and allows remote code execution as root, without authentication.

*Published on July 2, 2024*

<Warning>
  **CVE-2024-6387 — "RegreSSHion".** Race condition in `sshd`'s `SIGALRM` handler, triggerable remotely, no credentials needed. The end goal: `root` on the machine. Exploitation is slow (days rather than hours on most targets) and requires a payload tailored to the binary — but the public PoC proved it is entirely feasible.
</Warning>

## The story behind the bug

`CVE-2006-5051` was fixed in 2006. In 2020, an OpenSSH logging-code refactor reintroduced the same condition. Nobody spotted it for four years. Qualys dug it back up in June 2024 — hence the name "RegreSSHion", a contraction of *regression* and *SSH*.

## The mechanics

`sshd` enforces a maximum delay (`LoginGraceTime`, 120 seconds by default) for a client to complete authentication. When that delay expires, the kernel sends `SIGALRM` to the process, which fires a handler called `sigdie`. That handler calls logging functions (`syslog()`, etc.) which are **not** *async-signal-safe* — they can take locks, allocate memory, touch global structures.

If the attacker times the timer expiry precisely while `sshd` is itself manipulating those structures (typically during a concurrent logging operation), they trigger heap corruption. With enough attempts and a finely-tuned payload, that corruption turns into code execution in the privileged `sshd` process.

## Why the attack is slow without being theoretical

* It takes **tens of thousands of attempts** to win the race.
* Each attempt must wait for `LoginGraceTime` to expire.
* The payload must match the exact OpenSSH version **and** target libc.

On 32-bit glibc Debian, Qualys demonstrated exploitation in \~6-8 hours. On a recent 64-bit, they estimate 6-8 days per target. That is too slow for *spray and pray*, but well within reach for a targeted attack — and the exploit is becoming more industrialised.

## Are you affected?

Versions affected (Linux glibc):

* OpenSSH 4.4p1 → 8.5p1: not affected (the regression was introduced later).
* OpenSSH **8.5p1 → 9.7p1**: **vulnerable**.
* OpenSSH 9.8p1 and later: fixed.

Quick check:

```bash theme={null}
ssh -V
```

## Patches

Track your distribution's advisory:

| Distribution          | Patched version       |
| --------------------- | --------------------- |
| Ubuntu Jammy (22.04)  | `1:8.9p1-3ubuntu0.10` |
| Ubuntu Mantic (23.10) | `1:9.3p1-1ubuntu3.6`  |
| Ubuntu Noble (24.04)  | `1:9.6p1-3ubuntu13.3` |
| Debian Bullseye (11)  | `1:8.4p1-5+deb11u3`   |
| Debian Bookworm (12)  | `1:9.2p1-2+deb12u3`   |
| Debian Sid            | `1:9.7p1-7`           |

## Temporary mitigation

If you cannot patch right away, you can remove the race window by setting `LoginGraceTime 0` in `/etc/ssh/sshd_config`:

```text theme={null}
LoginGraceTime 0
```

Then reload:

```bash theme={null}
sudo systemctl reload ssh
```

<Note>
  This mitigation **exposes you to a trivial denial of service**: an attacker can open TCP connections that never authenticate and exhaust `sshd`'s pre-auth slots. Use it only as a last resort, until the patch lands.
</Note>

Surface-reduction measures you can apply without losing service:

* Restrict SSH access at the firewall to known IPs or ranges.
* Use `Match` + `AllowUsers` to narrow the reachable account surface.
* Add `fail2ban` on the auth log to slow attempt bursts.

## Verify after patching

```bash theme={null}
# The version must be beyond the vulnerable ranges
sudo sshd -V 2>&1 | head -1
```

## Wrap-up

A quiet regression, exploitable, and a reminder that old patches deserve regression tests. Patching is fast, the operational cost is minimal, and the residual risk of unauthenticated root RCE more than justifies not waiting.

For questions, open a ticket from your [OnetSolutions client area](https://onetsolutions.net).