Im in vielen Linux-Distributionen verwendeten Patch gssapi.patch, das OpenSSH Unterstützung für GSSAPI-basierten Schlüsselaustausch hinzufügt, wurde eine Schwachstelle (CVE-2026-3497) entdeckt, die zu einer Dereferenzierung eines Zeigers, zu Speicherbeschädigung und zu einem Umgehen des Privilegientrennungssystems (Privsep) führt. Die Schwachstelle kann aus der Ferne in der Phase vor der Authentifizierung ausgenutzt werden. Der den Fehler entdeckte Forscher demonstrierte eine Prozessabbruch-Initiierung durch das Senden eines modifizierten Netzwerkpakets an den SSH-Server. Es ist nicht auszuschließen, dass neben einem Denial-of-Service auch gefährlichere Ausnutzungen der Schwachstelle existieren.
Bemerkenswert ist, dass die Entwickler von OpenSSH seinerzeit die Annahme einer Änderung zur Unterstützung von GSSAPI aufgrund von Bedenken hinsichtlich der Sicherheit abgelehnt haben. Trotzdem haben viele Linux-Distributionen dieses Patch in ihre Pakete mit OpenSSH aufgenommen. Es gibt mehrere Versionen des GSSAPI-Patches im Umlauf, aber in den meisten von ihnen gibt es einen fehlerhaften, der zu der Schwachstelle führt. Eine Korrektur ist bisher nur in Form eines Patches verfügbar, dessen Änderungen sich darauf beschränken, den Funktionsaufruf sshpkt_disconnect() auf ssh_packet_disconnect() in der Datei kexgsss.c zu ersetzen.
Derzeit ist das Vorhandensein der Schwachstelle in Debian und Ubuntu bestätigt. In anderen Distributionen wird die Verwendung des problematischen Patches und deren Anfälligkeit für die Schwachstelle überprüft (SUSE/openSUSE, RHEL, Gentoo, Arch, Fedora). Die Schwachstelle tritt nur auf, wenn die Option "GSSAPIKeyExchange yes" in den Einstellungen aktiviert ist. Auf die Möglichkeit einer Ausnutzung hat auch Einfluss, mit welchen Compiler-Optionen das Paket in den Distributionen erstellt wurde.
Die Ursache für das Auftreten der Schwachstelle liegt in einem Fehler in der Funktion sshpkt_disconnect(), aufgrund dessen der Prozess nach dem Eingang einer Disconnect-Nachricht nicht beendet wurde, was es dem Angreifer ermöglichte, in der Phase des Schlüsselaustauschs eine nicht von der Logik vorgesehene... Server GSSAPI-Nachrichtentyp zu senden. Nach dem Empfang einer nicht vorgesehenen GSSAPI-Nachricht, Server Platziert es in einer Warteschlange und unterbricht die Ausführung des Programms nicht, initialisiert dabei jedoch nicht die Variablen, die die Verbindungsparameter definieren. Im weiteren Verlauf wird im Event-Handling-Zyklus Code ausgeführt, der die nicht initialisierte Struktur recv_tok aus dem Stapel liest (die Daten, die vom vorherigen Funktionsaufruf im Stapel verbleiben), sie über IPC an einen privilegierten Prozess sendet und dann an die Funktion gss_release_buffer() übergibt, die die Funktion free() aufrufen kann und Speicher für einen ungültigen Zeiger freigeben kann, der auf einen zufälligen Speicherbereich verweist.
Quelle: opennet.ru
