Das Unternehmen Qualys hat eine kritische Sicherheitsanfälligkeit (CVE-2024-6387) in OpenSSH aufgedeckt, die eine Remote-Codeausführung mit Root-Rechten ohne Authentifizierung ermöglicht. Die Schwachstelle, die den Codenamen regreSSHion trägt, tritt in der Standardkonfiguration ab Version OpenSSH 8.5 auf Systemen mit der Standardbibliothek Glibc auf.
Die Möglichkeit, einen Angriff durchzuführen, wurde auf einem 32-Bit-System mit Glibc und aktivem ASLR-Schutz (Address Space Layout Randomization) demonstriert. Für einen erfolgreichen Angriff im Laborumfeld waren 6-8 Stunden erforderlich, in denen Server ständig Verbindungen mit der maximal zulässigen Intensität gemäß der sshd-Konfiguration hergestellt wurden. Die Durchführung eines Angriffs wird auf Systemen ohne ASLR oder in Distributionen, die eine modifizierte Version von OpenSSH verwenden, bei der die erneute ASLR-Randomisierung für jede Verbindung deaktiviert ist, erleichtert und benötigt weniger Zeit. Ein funktionierender Exploit-Prototyp wird nicht öffentlich veröffentlicht, bis die Schwachstelle umfassend beseitigt wurde, jedoch ist eine ausreichend detaillierte Beschreibung der Schwachstelle verfügbar, die das Auftauchen von Drittanbieter-Exploits nur noch eine Frage der Zeit ist.
Ein Angriff auf 64-Bit-Systeme ist ebenfalls möglich, aber ein funktionierender Exploit für solche Systeme steht derzeit noch nicht zur Verfügung. Es wird angenommen, dass die Durchführung eines Angriffs auf 64-Bit-Systeme wesentlich mehr Zeit in Anspruch nehmen wird, aber nicht länger als eine Woche. OpenSSH in OpenBSD ist nicht betroffen, da in diesem System seit 2001 ein Schutzmechanismus eingesetzt wird, der solche Angriffe blockiert. In anderen Systemen, die auf anderen Standardbibliotheken als Glibc basieren, könnte die Methode theoretisch angepasst werden, um einen Angriff durchzuführen (dieses Thema wurde bei Qualys bisher nicht untersucht).
Die Schwachstelle wurde in der heute veröffentlichten Version OpenSSH 9.8 (Patch) behoben. Updates für Pakete in Distributionen können auf folgenden Seiten nachverfolgt werden: Debian, Ubuntu, RHEL, SUSE/openSUSE, Fedora, ROSA, Gentoo, ALT Linux, Arch und FreeBSD. Als Umgehungslösung zur Blockierung der Schwachstelle kann in der sshd_config der Parameter „LoginGraceTime=0“ gesetzt werden, wobei die Deaktivierung des Timeouts die Initiierung von Denial-of-Service-Angriffen bei einer großen Anzahl von Verbindungen, die die durch den Parameter MaxStartups festgelegten Grenzen überschreiten, erleichtert.
Ein Anzeichen für den Versuch eines Angriffs ist das Auftreten einer großen Anzahl von Einträgen "Timeout vor der Authentifizierung" im Protokoll.
Die Schwachstelle entstand durch eine regressiven Änderung, die in die Version OpenSSH 8.5 aufgenommen wurde und zu einem Race Condition im Code der Signalverarbeitung in sshd führt. Die Regression führte dazu, dass der Schutz gegen die alte Schwachstelle CVE-2006-5051, die bis zur Version OpenSSH 4.4 (2006) auftrat und theoretischer Natur war, nicht mehr wirksam war.
Im Verlauf der Entwicklung von OpenSSH 8.5 wurde versehentlich der Block "#ifdef DO_LOG_SAFE_IN_SIGHAND" aus der Funktion sigdie() entfernt, die direkt vom SIGALRM-Handler aufgerufen wird.
Der SIGALRM-Handler wird im sshd asynchron aufgerufen, wenn der Client die Authentifizierung innerhalb der durch den Verbindungszeitüberschreitung (LoginGraceTime, standardmäßig 120 Sek.) festgelegten Zeit nicht durchgeführt hat. Der Angriff basiert darauf, dass der Signalhandler Funktionen aufruft, die bei der asynchronen Signalverarbeitung unsicher sind, wie syslog(). Die Funktion syslog() in Glibc ist nicht für die Verwendung in asynchron ausgeführten Signalhandlern vorgesehen, da sie Funktionen wie malloc() und free() aufruft. Das Auslösen des SIGALRM-Signals, das die Ausführung bestimmter Codes in sshd unterbricht, kann zu einer Beeinträchtigung des Ausführungszustands führen, und das Ziel des Exploits besteht darin, Bedingungen zu schaffen, um den gewünschten Code zum richtigen Zeitpunkt seiner Ausführung zu unterbrechen. Die Schwachstelle betrifft OpenBSD nicht, da anstelle von syslog() aus dem SIGALRM-Signalhandler die Funktion syslog_r() aufgerufen wird, die speziell für den asynchronen Betrieb entwickelt wurde.
Quelle: opennet.ru
