RegreSSHion: RCE in OpenSSH's server, on glibc-based Linux systems

Original Article ↗ Hacker News Discussion ↗

A newly disclosed OpenSSH vulnerability (CVE-2024-6387, “regreSSHion”) allows remote, unauthenticated code execution as root on glibc-based Linux systems via a signal-handler race, with lab exploits succeeding after hours of sustained connection attempts. Commenters examine which OpenSSH and distro versions are affected or safe (notably musl- and OpenBSD-based systems), outline temporary mitigations such as changing `LoginGraceTime`, fail2ban, port knocking, VPN/WireGuard access, and emphasize promptly applying vendor patches. The conversation also revisits long‑standing concerns around signal safety in C, the small maintainer base for critical infrastructure like OpenSSH, and the limits of relying on any single hardening layer.

Vulnerability characteristics & exploitability

  • CVE-2024-6387 is a signal-handler race in sshd triggered when LoginGraceTime expires and a SIGALRM handler calls async‑unsafe logging.
  • On 32‑bit glibc systems, an RCE to root was demonstrated:
    • ~10,000 attempts to win the race.
    • With defaults like MaxStartups 100 and LoginGraceTime 120, lab results were ~3–4 hours to win the race, ~6–8 hours on average to get a root shell due to ASLR guesswork.
  • Exploitation on 64‑bit is considered likely but not yet publicly demonstrated.
  • Attack is noisy (many connections), but commenters note the internet is already full of slow SSH brute force, so adding this to botnets is plausible.

Affected systems and distro status

  • Versions:
    • Vulnerable: OpenSSH 8.5p1–9.7p1.
    • Not vulnerable: <4.4p1 (if patched for older CVEs), 4.4p1–8.4p1, and ≥9.8p1.
  • Confirmed/mentioned status:
    • Debian 12, Ubuntu 22.04/23.10/24.04, Fedora, Gentoo, Arch, FreeBSD, SUSE, Amazon Linux 2023, Rocky 9: patches in progress or released.
    • Many older LTS releases (e.g., Ubuntu 18.04, some RHEL versions) are unaffected due to older OpenSSH.
  • Ubuntu 24.04’s specific sshd behavior around ASLR (no per‑child re‑randomization) makes this particular exploit path ineffective, but it still received patches.

Mitigations and workarounds

  • Recommended:
    • Upgrade to a patched OpenSSH (9.8p1 or distro backport).
    • If unable to update: set LoginGraceTime 0 (eliminates the alarm handler, but allows easy DoS via connection exhaustion).
  • Other operational mitigations:
    • Use sshd -e (stderr logging) to avoid syslog in the handler; -D alone is insufficient.
    • Reduce MaxStartups or increase grace time to stretch exploit time, though not a full fix.
    • Restart sshd after upgrading; some users saw failed key exchange until restart.

fail2ban, port knocking, and VPNs

  • Broad agreement: these do not fix the bug but can raise the bar:
    • fail2ban blocks repeated remote attempts, but typically not localhost; distributed botnets can evade IP‑based bans.
    • Port knocking, SPA, IP whitelisting, and WireGuard/Tailscale/VPN fronting can hide or gate SSH; debate over whether this is “security theater” or effective defense‑in‑depth.
    • Some use SSH only over VPN or WireGuard and avoid exposing port 22 at all.

OpenBSD, musl, and signal‑safety

  • OpenBSD is not exploitable via this path because its syslog_r() is async‑signal‑safe and was designed that way long ago.
  • musl’s syslog implementation does not allocate and is guarded by locks; worst case is a deadlock, not memory corruption. musl maintainers state it is not vulnerable to this RCE.
  • Several comments emphasize that signal handlers should only use async‑signal‑safe operations, or better, just set a flag / write to a pipe and handle logic in the main loop.

Security process and OpenSSH development

  • The regression came from refactoring that removed a #ifdef guarding unsafe logging in a signal path.
  • Some see this as evidence of under‑resourced review on critical infrastructure; others note this is normal fallible open source and invite contributions instead of blame.
  • Discussion touches on bug‑bounty culture: vendors typically want full exploit chains; “theoretical” bugs without PoC often get ignored or under‑rewarded, which may discourage early disclosure.