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

Original Article ↗ Hacker News Discussion ↗

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.