CVE-2024-6387: regreSSHion — OpenSSH RCE After 18 Years

Eine Race Condition im Signal-Handler von OpenSSH erlaubt unauthentifizierten Angreifern, beliebigen Code als root auf Linux-Servern mit glibc auszuführen. „regreSSHion“ genannt — eine Regression von CVE-2006-5051, die 2020 versehentlich wieder eingeführt wurde. Betrifft ca. 14 Millionen internet-exponierte SSH-Server. CVSS 8.1 HIGH.

Was ist CVE-2024-6387?

CVE-2024-6387 ist eine Signal-Handler-Race-Condition im Server von OpenSSH (sshd). Wenn sich ein Client nicht innerhalb der LoginGraceTime (Standard: 120 Sekunden) authentifiziert, ruft sshd SIGALRM auf, um die Verbindung zu beenden. Der Signal-Handler ruft async-signal-unsichere Funktionen auf — konkret syslog() — die den Heap-Zustand beschädigen können, wenn sie gleichzeitig mit anderen Operationen aufgerufen werden.

Die Qualys-Forscher, die die Schwachstelle entdeckten, nannten sie „regreSSHion“, weil ein identischer Bug (CVE-2006-5051) 2006 behoben wurde, der Fix aber versehentlich entfernt wurde, als OpenSSH 8.5p1 im Oktober 2020 erschien — die Schwachstelle existierte also fast vier Jahre lang still wieder, bevor sie entdeckt wurde.

Betroffene Versionen

glibc-Voraussetzung: Der Qualys-PoC nutzte die malloc-Implementierung von glibc aus. Der sshd von OpenBSD ist nicht verwundbar. Alpine Linux (das musl libc nutzt) und macOS sind für die demonstrierte Ausnutzungstechnik nicht verwundbar, obwohl die Race Condition weiterhin existiert.

Die Race Condition erklärt

Signal-Handler in C-Programmen dürfen nur „async-signal-safe“-Funktionen aufrufen — eine kleine Teilmenge von libc-Funktionen, die aus einem Signal-Handler heraus sicher aufrufbar sind, weil sie keinen geteilten Zustand nutzen. Die Funktion syslog() ist nicht async-signal-safe, weil sie intern malloc nutzt.

# The problematic code path (simplified):
# When LoginGraceTime expires:
SIGALRM → grace_alarm_handler() → syslog() → malloc() internally
                                              ↕ RACE
           main sshd thread also calls        malloc() / free()

# If both malloc operations interleave:
# → Heap corruption
# → With enough attempts: controlled heap layout
# → Remote code execution as root

Die Ausnutzung erfordert, die Race Condition zuverlässig zu gewinnen, was Tausende Verbindungsversuche über Minuten erfordert. Das macht automatisierte Ausnutzung im Internet-Maßstab etwas langsamer als typische „Fire-and-forget“-Schwachstellen — aber versierte Akteure mit dauerhaftem Zugriff auf ein Ziel haben reichlich Zeit.

Schwierigkeit der Ausnutzung

Qualys demonstrierte zuverlässige Ausnutzung auf 32-Bit-Systemen (x86). Auf 64-Bit-Systemen erhöht ASLR die Schwierigkeit deutlich. Die Forscher merken an, dass mit ~10.000 Versuchen über 6–8 Stunden Ausnutzung auf 64-Bit-Systemen theoretisch erreichbar ist, sie veröffentlichten aber keinen funktionierenden PoC für x86_64.

Die Hürde kann jedoch gesenkt werden durch:

• Informationslecks, die ASLR aushebeln (kombinierte Exploits)
• Brute-Forcing in Umgebungen, in denen fail2ban oder Rate-Limiting nicht konfiguriert ist
• Künftige Forschung, die die Ausnutzungstechnik verbessert
• Zugriff auf verwundbare 32-Bit-Systeme (in IoT und Embedded Linux noch verbreitet)

Erkennung

# Check OpenSSH version
ssh -V
sshd -V

# Check installed package version (Debian/Ubuntu)
dpkg -l openssh-server | grep openssh

# Check installed package version (RHEL/CentOS)
rpm -qa | grep openssh-server

# Check for brute-force attempts indicative of regreSSHion exploitation
# (very high connection rate from single IP, all failing within grace period)
grep "Connection closed by" /var/log/auth.log | 
  awk '{print $9}' | sort | uniq -c | sort -rn | head -20

# Check for failed logins at high rate
grep "Failed\|Invalid" /var/log/auth.log | 
  awk '{print $11}' | sort | uniq -c | sort -rn | head -10

Mitigation

1. OpenSSH auf 9.8p1+ aktualisieren: Alle großen Distributionen veröffentlichten Patches innerhalb von Tagen nach der Offenlegung. apt update && apt upgrade openssh-server oder Äquivalent.
2. LoginGraceTime auf 0 setzen: LoginGraceTime 0 in /etc/ssh/sshd_config zu setzen verhindert, dass der SIGALRM-Handler aufgerufen wird, und eliminiert die Race Condition (entfernt jedoch das Grace-Timeout):

   echo "LoginGraceTime 0" >> /etc/ssh/sshd_config
   systemctl reload sshd

3. SSH-Verbindungen ratenbegrenzen: Konfigurieren Sie fail2ban oder iptables-Rate-Limiting, um die für die Ausnutzung nötigen Tausenden Verbindungen zu verhindern
4. SSH-Zugriff per IP beschränken: Begrenzen Sie sshd auf bekannte Management-IP-Bereiche mittels AllowUsers, ListenAddress oder Firewall-Regeln
5. Nur SSH-Keys verwenden: Deaktivieren Sie Passwort-Authentifizierung — key-basierte Auth fügt einen starken Pre-Authentication-Filter hinzu
6. SSH auf einen Nicht-Standard-Port verlegen (erwägen): Reduziert opportunistisches Scanner-Rauschen, ist aber keine Sicherheitskontrolle

KENSAI-Erkennungsfähigkeit

• SSH-Banner-Scanning: KENSAI identifiziert OpenSSH-Versionen über alle internet-gerichteten Assets und markiert 8.5p1–9.7p1 als verwundbar für CVE-2024-6387
• Internes Netzwerk-Scanning: Umfassende Erkennung verwundbarer SSH-Server in internen Netzwerken
• Konfigurations-Audit: Prüft auf mitigierende Konfigurationen (LoginGraceTime, AllowUsers, Key-only-Auth)
• Patch-Validierung: Bestätigt die Patch-Anwendung nach der Behebung
• Exposure-Kontext: Priorisiert internet-exponierte SSH-Server gegenüber rein internen Systemen