Mehrere Schwachstellen in OpenSSH (Feb. 2025)

[English]Sicherheitsexperten von Qualys TRU sind bei der Software OpenSSH auf zwei Schwachstellen gestoßen. Zudem wurde am 11. Februar 2024 ein Advisory zu einer weiteren Schwachstelle veröffentlicht. Betroffen von dieser Schwachstelle sind OpenSSL 3.4, 3.3 und 3.2, wobei es Upgrades auf neuere OpenSSL-Versionen gibt.

Was ist OpenSSH?

OpenSSH ist eine kostenlose Open-Source-Implementierung des Secure Shell (SSH)-Protokolls, das verschlüsselte Kommunikation über unsichere Netzwerke ermöglicht und eine Dateiübertragung ermöglicht. Es ist in Unix-ähnlichen Systemen (einschließlich Linux und macOS) und vielen modernen Betriebssystemen weit verbreitet und ersetzt Klartextprotokolle wie Telnet und FTP durch sichere Remote-Anmeldung, Dateiübertragung, Port-Weiterleitung und Tunneling. Das Programmpaket nutzt Secure Shell inklusive SSH File Transfer Protocol und beinhaltet dafür Clients, Dienstprogramme und einen Server.

Schwachstelle CVE-2024-12797 in OpenSSH

Bereits zum 11. Februar 2025 ist auf Openwall der Sicherheitshinweis OpenSSL: RFC7250 handshakes with unauthenticated servers don't abort as expected (CVE-2024-12797) erschienen.

Clients, die RFC7250 Raw Public Keys (RPKs) zur Authentifizierung eines Server verwenden, bemerken möglicherweise nicht, dass der Server nicht authentifiziert wurde, weil Handshakes nicht wie erwartet abgebrochen werden, wenn der SSL_VERIFY_PEER Verifizierungsmodus eingestellt ist.

TLS- und DTLS-Verbindungen, die Raw Public Keys (RPKs) verwenden, können anfällig für Man-in-Middle-Angriffe sein, wenn die Server-Authentifizierung nicht von den Clients erkannt wird.

RPKs sind standardmäßig sowohl in TLS-Clients als auch in TLS-Servern deaktiviert. Das Problem tritt nur dann auf, wenn TLS-Clients die Verwendung von RPKs durch den Server explizit aktivieren und der Server ebenfalls das Senden eines RPKs anstelle einer X.509-Zertifikatskette Kette verwendet. Die betroffenen Clients sind diejenigen, die sich dann darauf verlassen, dass der Handshake fehlschlägt, wenn der RPK des Servers nicht mit einem der erwarteten öffentlichen Schlüssel übereinstimmt, indem sie den Verifizierungsmodus auf SSL_VERIFY_PEER setzen, heißt es im Sicherheitshinweis.

Clients, die serverseitige RPKs aktivieren, können immer noch herausfinden, dass die Verifizierung des Schlüssels fehlgeschlagen ist, indem sie SSL_get_verify_result() aufrufen, und entsprechende Maßnahmen ergreifen. Dieses Problem ist bereits bei der ursprünglichen Implementierung der RPK-Unterstützung in OpenSSL 3.2 in den Code eingeflossen. Dieses Problem wurde am 18. Dezember 2024 von Apple Inc. gemeldet.

Betroffen von dieser Schwachstelle sind die OpenSSL Versionen 3.4, 3.3 und 3.2. Nicht betroffen sind OpenSSL 3.1, 3.0, 1.1.1 und 1.0.2  sowie die FIPS-Module in 3.4, 3.3, 3.2, 3.1 und 3.0. Es gibt aber Updates:

• Benutzer von OpenSSL 3.4 sollten ein Upgrade auf OpenSSL 3.4.1 durchführen.
• Benutzer von OpenSSL 3.3 sollten ein Upgrade auf OpenSSL 3.3.2 durchführen.
• Benutzer von OpenSSL 3.2 sollten ein Upgrade auf OpenSSL 3.2.4 durchführen.

Der Fix wurde von Viktor Dukhovni entwickelt. Das Advisory lässt sich als Textversion hier einsehen. Hunter weist in nachfolgendem Post vom 12.2.2025 auf die Schwachstelle hin und dass über 71 Millionen OpenSSH-Dienste gefunden wurden.

OpenSSH Schwachstellen CVE-2025-26465 & CVE-2025-26466

Die Qualys Threat Research Unit (TRU) hat die zwei Schwachstellen CVE-2025-26465 und CVE-2025-26466 in OpenSSH entdeckt.

• CVE-2025-26465 ermöglicht einen aktiven Man-in-the-Middle-Angriff auf den OpenSSH-Client, wenn die Option VerifyHostKeyDNS aktiviert ist.
• CVE-2025-26466 betrifft sowohl den OpenSSH-Client als auch den Server und ermöglicht einen Denial-of-Service-Angriff vor der Authentifizierung.

Der Angriff auf den OpenSSH-Client (CVE-2025-26465) ist unabhängig davon, ob die Option VerifyHostKeyDNS auf „yes" oder „ask" gesetzt ist (die Standardeinstellung ist „no"), erfolgreich, erfordert keine Benutzerinteraktion und hängt nicht von der Existenz eines SSHFP-Ressourceneintrags (eines SSH-Fingerprints) im DNS ab.

VerifyHostKeyDNS ist eine OpenSSH-Clientkonfigurationsoption, die es dem SSH-Client ermöglicht, den Hostschlüssel eines Servers anhand von DNS-Einträgen (insbesondere SSHFP-Einträgen) zu suchen und zu überprüfen.

Die Schwachstelle wurde im Dezember 2014 kurz vor der Veröffentlichung von OpenSSH 6.8p1 bekannt. Obwohl VerifyHostKeyDNS standardmäßig deaktiviert ist, war es unter FreeBSD von September 2013 bis März 2023 standardmäßig aktiviert.

Der OpenSSH-Client und -Server sind anfällig (CVE-2025-26466) für einen Denial-of-Service-Angriff vor der Authentifikation – eine asymmetrische Nutzung von Speicher- und CPU-Ressourcen -, der im August 2023 (kurz vor der Veröffentlichung von OpenSSH 9.5p1) eingeführt wurde. Auf der Serverseite kann dieser Angriff durch die Verwendung bestehender Mechanismen in OpenSSH, wie LoginGraceTime, MaxStartups und die neueren PerSourcePenalties, abgeschwächt werden. Betroffen sind folgende OpenSSH-Versionen:

• OpenSSH-Versionen von 6.8p1 bis 9.9p1 sind anfällig für die im Dezember 2014 bekannt gewordene Schwachstelle CVE-2025-2646.
• OpenSSH-Versionen 9.5p1 bis 9.9p1 sind anfällig für die im August 2023 bekannt gewordene Schwachstelle CVE-2025-26466.

OpenSSH 9.9p2 behebt die oben genannten Schwachstellen. Um die Sicherheit weiterhin zu gewährleisten, wird dringend empfehlen, betroffene Systeme so schnell wie möglich auf 9.9p2 zu aktualisieren.