{"id":308654,"date":"2025-02-19T08:57:59","date_gmt":"2025-02-19T07:57:59","guid":{"rendered":"https:\/\/www.borncity.com\/blog\/?p=308654"},"modified":"2025-02-20T12:21:02","modified_gmt":"2025-02-20T11:21:02","slug":"schwachstellen-cve-2024-12797-in-openssh-feb-2025","status":"publish","type":"post","link":"https:\/\/borncity.com\/blog\/2025\/02\/19\/schwachstellen-cve-2024-12797-in-openssh-feb-2025\/","title":{"rendered":"Mehrere Schwachstellen in OpenSSH (Feb. 2025)"},"content":{"rendered":"

\"Sicherheit[English<\/a>]Sicherheitsexperten von Qualys TRU sind bei der Software OpenSSH auf zwei Schwachstellen gesto\u00dfen. Zudem wurde am 11. Februar 2024 ein Advisory zu einer weiteren Schwachstelle ver\u00f6ffentlicht. Betroffen von dieser Schwachstelle sind OpenSSL 3.4, 3.3 und 3.2, wobei es Upgrades auf neuere OpenSSL-Versionen gibt.<\/p>\n

<\/p>\n

Was ist OpenSSH?<\/h2>\n

\"\"OpenSSH<\/a> ist eine kostenlose Open-Source-Implementierung des Secure Shell (SSH)-Protokolls, das verschl\u00fcsselte Kommunikation \u00fcber unsichere Netzwerke erm\u00f6glicht und eine Datei\u00fcbertragung erm\u00f6glicht. Es ist in Unix-\u00e4hnlichen Systemen (einschlie\u00dflich Linux und macOS) und vielen modernen Betriebssystemen weit verbreitet und ersetzt Klartextprotokolle wie Telnet und FTP durch sichere Remote-Anmeldung, Datei\u00fcbertragung, Port-Weiterleitung und Tunneling. Das\u00a0Programmpaket nutzt Secure Shell inklusive SSH File Transfer Protocol und beinhaltet daf\u00fcr Clients, Dienstprogramme und einen Server.<\/p>\n

Schwachstelle CVE-2024-12797 in OpenSSH<\/h2>\n

Bereits zum 11. Februar 2025 ist auf Openwall der Sicherheitshinweis\u00a0OpenSSL: RFC7250 handshakes with unauthenticated servers don't abort as expected<\/a> (CVE-2024-12797)\u00a0erschienen.<\/p>\n

Clients, die RFC7250 Raw Public Keys (RPKs) zur Authentifizierung eines Server verwenden, bemerken m\u00f6glicherweise nicht, dass der Server nicht authentifiziert wurde, weil Handshakes nicht wie erwartet abgebrochen werden, wenn der SSL_VERIFY_PEER Verifizierungsmodus eingestellt ist.<\/p>\n

TLS- und DTLS-Verbindungen, die Raw Public Keys (RPKs) verwenden, k\u00f6nnen anf\u00e4llig f\u00fcr Man-in-Middle-Angriffe sein, wenn die Server-Authentifizierung nicht von den Clients erkannt wird.<\/p>\n

RPKs sind standardm\u00e4\u00dfig 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\u00e4gt, wenn der RPK des Servers nicht mit einem der erwarteten \u00f6ffentlichen Schl\u00fcssel \u00fcbereinstimmt, indem sie den Verifizierungsmodus auf SSL_VERIFY_PEER setzen, hei\u00dft es im Sicherheitshinweis.<\/p>\n

Clients, die serverseitige RPKs aktivieren, k\u00f6nnen immer noch herausfinden, dass die Verifizierung des Schl\u00fcssels fehlgeschlagen ist, indem sie SSL_get_verify_result() aufrufen, und entsprechende Ma\u00dfnahmen ergreifen. Dieses Problem ist bereits bei der urspr\u00fcnglichen Implementierung der RPK-Unterst\u00fctzung in OpenSSL 3.2 in den Code eingeflossen. Dieses Problem wurde am 18. Dezember 2024 von Apple Inc. gemeldet.<\/p>\n

Betroffen von dieser Schwachstelle sind die\u00a0OpenSSL Versionen 3.4, 3.3 und 3.2. Nicht betroffen sind OpenSSL 3.1, 3.0, 1.1.1 und 1.0.2\u00a0 sowie die\u00a0FIPS-Module in 3.4, 3.3, 3.2, 3.1 und 3.0. Es gibt aber Updates:<\/p>\n