Wird in vielen Vertriebskanälen verwendet Linux In dem Patch gssapi.patch, der OpenSSH um GSSAPI-basierte Schlüsselaustauschunterstützung erweitert, wurde eine Sicherheitslücke (CVE-2026-3497) entdeckt. Diese Sicherheitslücke ermöglicht das Dereferenzieren von Zeigern, Speicherbeschädigung und das Umgehen der Privilegientrennung (Privsep). Die Sicherheitslücke kann vor der Authentifizierung aus der Ferne ausgenutzt werden. Der Entdecker demonstrierte, wie ein Prozessabsturz durch das Senden eines einzelnen manipulierten Netzwerkpakets an einen SSH-Server herbeigeführt werden kann. Es ist möglich, dass neben Denial-of-Service-Angriffen noch weitere, gefährlichere Angriffe existieren.
Es ist erwähnenswert, dass die OpenSSH-Entwickler sich einst aufgrund von Sicherheitsbedenken weigerten, eine Änderung zur Unterstützung von GSSAPI in den Hauptzweig aufzunehmen. Inzwischen haben viele Distributionen Linux Sie haben diesen Patch in ihre OpenSSH-Pakete aufgenommen. Mehrere Versionen des GSSAPI-Patches sind im Umlauf, die meisten weisen jedoch eine Sicherheitslücke auf. Die Behebung ist derzeit nur als Patch verfügbar, der den Funktionsaufruf `sshpkt_disconnect()` in der Datei `kexgsss.c` durch `ssh_packet_disconnect()` ersetzt.
Aktuell wurde die Schwachstelle bestätigt in Debian и UbuntuFür andere Distributionen (SUSE/openSUSE, RHEL, Gentoo, Arch, Fedora) werden die Verwendung des Patches und die Sicherheitslücke derzeit noch genauer untersucht. Die Sicherheitslücke tritt nur dann auf, wenn die Option „GSSAPIKeyExchange yes“ in den Einstellungen aktiviert ist. Die Compileroptionen, die zum Erstellen des Pakets in diesen Distributionen verwendet wurden, beeinflussen ebenfalls die Ausnutzbarkeit.
Die Schwachstelle wird durch einen Fehler in der Funktion sshpkt_disconnect() verursacht, wodurch der Prozess nach dem Empfang einer Trennungsnachricht nicht beendet wurde. Dies ermöglichte es einem Angreifer, in der Schlüsselaustauschphase eine Nachricht zu senden, die von der Betriebslogik nicht vorgesehen war. Server GSSAPI-Nachrichtentyp. Beim Empfang einer ungeplanten GSSAPI-Nachricht, Server Es wird in eine Warteschlange gestellt und die Programmausführung nicht unterbrochen, die Variablen, die die Verbindungsparameter definieren, werden jedoch nicht initialisiert. Anschließend wird in der Ereignisschleife Code ausgeführt, der die nicht initialisierte recv_tok-Struktur vom Stack liest (die vom vorherigen Funktionsaufruf verbliebenen Daten werden gelesen), sie über IPC an den privilegierten Prozess sendet und sie dann an die Funktion gss_release_buffer() übergibt. Diese kann die Funktion free() aufrufen und den Speicher für den ungültigen Zeiger, der auf eine zufällige Speicheradresse verweist, freigeben.
Source: opennet.ru
