Eine Korrekturversion von OpenSSH 9.9p2 ist verfügbar, in der zwei Schwachstellen behoben wurden, die von der Firma Qualys entdeckt wurden. Ein Beispiel für die Ausnutzung dieser Schwachstellen wurde demonstriert, um einen MITM-Angriff durchzuführen, der es ermöglicht, den Traffic beim Versuch einer Client-Verbindung zu einem SSH-Server auf einen eigenen gefälschten Server umzuleiten, die Überprüfung der Hostschlüssel zu umgehen und dem Client die Illusion einer Verbindung zum gewünschten Server zu geben (der SSH-Client akzeptiert den Hostschlüssel des gefälschten Servers anstelle des Schlüssels des legitimen Servers).
Die erste Schwachstelle (CVE-2025-26465) wird durch einen logischen Fehler in der ssh-Utility verursacht, der es ermöglicht, die Serveridentifikation zu umgehen und einen MITM-Angriff durchzuführen. Das Problem tritt ab der Version OpenSSH 6.8p1 (Dezember 2014) in Konfigurationen mit aktivierter Option VerifyHostKeyDNS auf. In der Standardinstallation von OpenSSH ist diese Option standardmäßig deaktiviert, wurde jedoch bis März 2023 in den SSH-Einstellungen von FreeBSD aktiviert.
Das Kernproblem liegt darin, dass im Code der Funktion verify_host_key_callback() bei der Aufrufung der Funktion verify_host_key() nur der Fehlercode „-1“ überprüft wird, während andere Codes wie „-2“ ignoriert werden. Daher kann die Funktion verify_host_key_callback() einen erfolgreichen Code „0“ zurückgeben, obwohl die Funktion verify_host_key() den Fehler „-2“ zurückgibt. Der Fehlercode „-2“ wird von der Funktion verify_host_key() zurückgegeben, wenn nicht genügend Speicher zur Verfügung steht. Wenn Bedingungen geschaffen werden, die dazu führen, dass kein Speicher in der verify_host_key()-Funktion zugewiesen werden kann, wird SSH denken, dass der Hostschlüssel erfolgreich überprüft wurde. Um solche Bedingungen zu erzeugen, gibt der gefälschte SSH-Server des Angreifers, auf den der Client umgeleitet wird, den Hostschlüssel mit maximaler Größe (256KB) zurück und gleichzeitig wird ein Speicherleck auf der Seite des SSH-Clients ausgenutzt.
Die Bedingungen für das Entstehen eines Speicherlecks werden durch die zweite Schwachstelle (CVE-2025-26466) erreicht, die sowohl den SSH-Client als auch der Server sshd betrifft und ohne Authentifizierung ausgenutzt werden kann. Die Schwachstelle erlaubt es, den für den Prozess verfügbaren Speicher zu erschöpfen und eine hohe CPU-Last zu erzeugen, indem eine große Anzahl von SSH2_MSG_PING-Paketen gesendet wird. Im Handler für SSH2_MSG_PING gibt es ein Speicherleck, das ab der Version OpenSSH 9.5p1 (August 2023) auftritt. Das Leck tritt auf, weil für jedes eingehende 16-Byte-PING-Paket ein 256-Byte-Puffer zur Antwortbildung zugewiesen wird, aber dieser Puffer wird nur nach Abschluss des Schlüsselaustauschs freigegeben. Als Umgehungslösung wird empfohlen, Einschränkungen mit den Direktiven LoginGraceTime, MaxStartups und PerSourcePenalties einzurichten.
Quelle: opennet.ru
