Skip to main content

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.

Published on July 2, 2024
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.

​
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: 
ssh -V

​
Patches

Track your distribution’s advisory:
DistributionPatched 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 Sid1: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: 
LoginGraceTime 0
Then reload: 
sudo systemctl reload ssh
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.
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

# 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.