CVE-2024-6387: regreSSHion — OpenSSH-RCE nach 18 Jahren

Eine Race Condition im Signal-Handler von OpenSSH ermöglicht es nicht authentifizierten Angreifern, beliebigen Code mit Root-Rechten auf Linux-Servern auszuführen, die glibc verwenden. Die Schwachstelle erhielt den Namen „regreSSHion“ — eine Regression von CVE-2006-5051, die 2020 versehentlich erneut eingeführt wurde. Betroffen sind etwa 14 Millionen über das Internet erreichbare SSH-Server. CVSS 8.1 HOCH.

Was ist CVE-2024-6387?

CVE-2024-6387 ist eine Race Condition im Signal-Handler des OpenSSH-Servers (sshd). Wenn sich ein Client nicht innerhalb der LoginGraceTime (Standardwert: 120 Sekunden) authentifiziert, ruft sshd SIGALRM auf, um die Verbindung zu beenden. Der Signal-Handler ruft Funktionen auf, die nicht asynchron-signalsicher sind — insbesondere syslog() — und dadurch den Heap-Zustand beschädigen können, wenn sie gleichzeitig mit anderen Operationen ausgeführt werden.

Die Qualys-Forscher, die die Schwachstelle entdeckten, nannten sie „regreSSHion“, weil ein identischer Fehler (CVE-2006-5051) bereits 2006 behoben worden war, die Korrektur jedoch mit der Veröffentlichung von OpenSSH 8.5p1 im Oktober 2020 unbeabsichtigt entfernt wurde — die Schwachstelle bestand somit fast vier Jahre lang unbemerkt erneut.

Betroffene Versionen

glibc-Anforderung: Der PoC von Qualys nutzte die malloc-Implementierung von glibc aus. Der sshd von OpenBSD ist nicht anfällig. Alpine Linux (das musl libc verwendet) und macOS sind gegenüber der demonstrierten Ausnutzungstechnik nicht anfällig, obwohl die Race Condition weiterhin besteht.

Erklärung der Race Condition

Signal-Handler in C-Programmen dürfen ausschließlich „asynchron-signalsichere“ Funktionen aufrufen — eine kleine Teilmenge der libc-Funktionen, die sicher aus einem Signal-Handler heraus aufgerufen werden können, da sie keinen gemeinsam genutzten Zustand verwenden. Die Funktion syslog() ist nicht asynchron-signalsicher, weil sie intern malloc verwendet.

# Der problematische Codepfad (vereinfacht):
# Wenn LoginGraceTime abläuft:
SIGALRM → grace_alarm_handler() → syslog() → malloc() intern
                                              ↕ RACE CONDITION
           Haupt-Thread von sshd ruft ebenfalls malloc() / free() auf

# Wenn sich beide malloc-Operationen überschneiden:
# → Heap-Beschädigung
# → Bei genügend Versuchen: kontrolliertes Heap-Layout
# → Ausführung von Remote-Code mit Root-Rechten

Für eine erfolgreiche Ausnutzung muss die Race Condition zuverlässig gewonnen werden, was Tausende Verbindungsversuche über mehrere Minuten erfordert. Dadurch ist die automatisierte Ausnutzung im Internet etwas langsamer als bei typischen „Fire-and-Forget“-Schwachstellen — doch technisch versierte Angreifer mit dauerhaftem Zugriff auf ein Ziel haben ausreichend Zeit.

Schwierigkeit der Ausnutzung

Qualys demonstrierte eine zuverlässige Ausnutzung auf 32-Bit-Systemen (x86). Auf 64-Bit-Systemen erhöht ASLR die Schwierigkeit erheblich. Die Forscher weisen darauf hin, dass eine Ausnutzung mit etwa 10.000 Versuchen über einen Zeitraum von 6–8 Stunden theoretisch auf 64-Bit-Systemen möglich ist, veröffentlichten jedoch keinen funktionsfähigen PoC für x86_64.

Die Hürde kann jedoch durch Folgendes gesenkt werden:

• Informationslecks, die ASLR aushebeln (kombinierte Exploits)
• Brute-Force-Angriffe in Umgebungen, in denen fail2ban oder eine Ratenbegrenzung nicht konfiguriert ist
• Künftige Forschung zur Verbesserung der Ausnutzungstechnik
• Zugriff auf anfällige 32-Bit-Systeme (in IoT- und eingebetteten Linux-Systemen weiterhin verbreitet)

Erkennung

# OpenSSH-Version prüfen
ssh -V
sshd -V

# Installierte Paketversion prüfen (Debian/Ubuntu)
dpkg -l openssh-server | grep openssh

# Installierte Paketversion prüfen (RHEL/CentOS)
rpm -qa | grep openssh-server

# Auf Brute-Force-Versuche prüfen, die auf eine Ausnutzung von regreSSHion hindeuten
# (sehr hohe Verbindungsrate von einer einzelnen IP, alle innerhalb der Karenzzeit fehlgeschlagen)
grep "Connection closed by" /var/log/auth.log |
  awk '{print $9}' | sort | uniq -c | sort -rn | head -20

# Auf eine hohe Rate fehlgeschlagener Anmeldungen prüfen
grep "Failed\|Invalid" /var/log/auth.log |
  awk '{print 1}' | sort | uniq -c | sort -rn | head -10

Schutzmaßnahmen

1. OpenSSH auf 9.8p1+ aktualisieren: Alle großen Distributionen veröffentlichten innerhalb weniger Tage nach der Offenlegung Patches. apt update && apt upgrade openssh-server oder ein entsprechender Befehl.
2. LoginGraceTime auf 0 setzen: Durch die Einstellung LoginGraceTime 0 in /etc/ssh/sshd_config wird verhindert, dass der SIGALRM-Handler aufgerufen wird. Dadurch wird die Race Condition beseitigt, allerdings entfällt auch die Karenzzeit:

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

3. SSH-Verbindungen begrenzen: fail2ban oder eine Ratenbegrenzung mit iptables konfigurieren, um die Tausenden Verbindungen zu verhindern, die für eine Ausnutzung erforderlich sind
4. SSH-Zugriff nach IP beschränken: sshd mithilfe von AllowUsers, ListenAddress oder Firewall-Regeln auf bekannte Verwaltungs-IP-Bereiche beschränken
5. Nur SSH-Schlüssel verwenden: Passwortauthentifizierung deaktivieren — die schlüsselbasierte Authentifizierung bietet einen starken Filter vor der eigentlichen Authentifizierung
6. Verlegung von SSH auf einen nicht standardmäßigen Port erwägen: Reduziert das Rauschen opportunistischer Scanner, ist jedoch keine Sicherheitskontrolle

Erkennungsfunktionen von KENSAI

• SSH-Banner-Scanning: KENSAI identifiziert OpenSSH-Versionen auf allen mit dem Internet verbundenen Assets und kennzeichnet 8.5p1–9.7p1 als anfällig für CVE-2024-6387
• Scannen interner Netzwerke: Umfassende Erkennung anfälliger SSH-Server in internen Netzwerken
• Konfigurationsprüfung: Prüft auf risikomindernde Konfigurationen (LoginGraceTime, AllowUsers, reine Schlüssel-Authentifizierung)
• Patch-Validierung: Bestätigt nach der Behebung, dass der Patch angewendet wurde
• Expositionskontext: Priorisiert über das Internet erreichbare SSH-Server gegenüber ausschließlich intern zugänglichen Systemen