Im in vielen Linux-Distributionen verwendeten Patch gssapi.patch, der OpenSSH Unterstützung für den Austausch von Schlüsseln basierend auf GSSAPI hinzufügt, wurde eine Sicherheitsanfälligkeit (CVE-2026-3497) festgestellt, die zu einem Dereferenzieren von Zeigern, Speicherbeschädigung und Umgehung des Mechanismus zur Trennung von Rechten (Privsep) führt. Die Sicherheitsanfälligkeit kann aus der Ferne vor der Authentifizierung ausgenutzt werden. Der entdeckende Forscher demonstrierte, wie durch das Senden eines modifizierten Netzwerkpakets an den SSH-Server der Prozess abstürzt. Es ist nicht auszuschließen, dass neben einer Dienstunterbrechung gefährlichere Ausnutzungen der Sicherheitsanfälligkeit existieren.
Es ist bemerkenswert, dass die Entwickler von OpenSSH ursprünglich die Aufnahme einer Änderung zur Unterstützung von GSSAPI aufgrund von Sicherheitsbedenken abgelehnt haben. Dennoch haben viele Linux-Distributionen diesen Patch in ihre Pakete mit OpenSSH aufgenommen. Es gibt mehrere Versionen des GSSAPI-Patches im Umlauf, von denen die meisten jedoch einen Fehler enthalten, der zu einer Sicherheitsanfälligkeit führt. Eine Behebung ist bislang nur in Form eines Patches verfügbar, der sich auf den Austausch des Funktionsaufrufs sshpkt_disconnect() gegen ssh_packet_disconnect() in der Datei kexgsss.c beschränkt.
Derzeit ist die Sicherheitsanfälligkeit in Debian und Ubuntu bestätigt. Bei anderen Distributionen wird die Anwendung des problematischen Patches und seine Verwundbarkeit noch untersucht (SUSE/openSUSE, RHEL, Gentoo, Arch, Fedora). Die Sicherheitsanfälligkeit tritt nur auf, wenn die Option «GSSAPIKeyExchange yes» in den Einstellungen aktiviert ist. Auch die Kompilierungsoptionen, mit denen das Paket in den Distributionen erstellt wurde, beeinflussen die Möglichkeit der Ausnutzung.
Die Ursache für die Entstehung der Sicherheitsanfälligkeit ist ein Fehler in der Funktion sshpkt_disconnect(), durch den der Prozess nach dem Empfang einer Disconnect-Nachricht nicht beendet wurde. Dies ermöglichte es einem Angreifer, in der Schlüsselverhandlungsphase eine nicht logische Nachricht zu senden. сервера Typ der GSSAPI-Nachricht. Nach dem Empfang einer unerwarteten GSSAPI-Nachricht, der Server wird sie in eine Warteschlange eingefügt, und die Programmausführung nicht unterbrochen, wobei jedoch die Variablen, die die Verbindungsparameter definieren, nicht initialisiert werden. Im weiteren Verlauf wird im Ereignisverarbeitungszyklus Code ausgeführt, der die nicht initialisierte Struktur recv_tok aus dem Stack liest (es werden Daten gelesen, die vom vorherigen Funktionsaufruf im Stack verbleiben), sie einem privilegierten Prozess über IPC zusendet und dann an die Funktion gss_release_buffer() übergibt, die die Funktion free() aufrufen kann und Speicher für einen ungültigen Zeiger freigibt, der auf einen zufälligen Speicherbereich verweist.
Quelle: opennet.ru
