OpenSSH 8.9 mit Behebung einer Sicherheitsanfälligkeit in sshd wurde veröffentlicht.

Nach sechsmonatiger Entwicklung wurde die Version OpenSSH 8.9 veröffentlicht, eine Open-Source-Implementierung von Client und Server zur Verwendung mit den Protokollen SSH 2.0 und SFTP. In der neuen Version wurde im sshd eine Vulnerabilität behoben, die potenziell den Zugang ohne Authentifizierung ermöglichen könnte. Das Problem wurde durch einen Integer-Überlauf im Authentifizierungscode verursacht, jedoch ist eine Ausnutzung nur in Kombination mit anderen logischen Fehlern im Code möglich.

In der aktuellen Form ist die Vulnerabilität nicht ausnutzbar, wenn der Privilegientrenmodus aktiviert ist, da seine Auswirkungen durch spezifische Überprüfungen im Code des Privilegientrennsystems blockiert werden. Der Privilegientrenmodus wurde standardmäßig im Jahr 2002 mit OpenSSH 3.2.2 aktiviert und ist seit der Veröffentlichung von OpenSSH 7.5 im Jahr 2017 verpflichtend. Darüber hinaus wird die Vulnerabilität in tragbaren Versionen von OpenSSH, beginnend mit Version 6.5 (2014), durch die Kompilierung mit aktivierten Schutzflags gegen Integer-Überläufe blockiert.

Weitere Änderungen:

• In der portablen Version von OpenSSH wurde die integrierte Unterstützung für die Passwort-Hashing-Algorithmus MD5 im sshd entfernt (für Rückgewinnungen ist die Verknüpfung mit externen Bibliotheken wie libxcrypt zulässig).
• Für ssh, sshd, ssh-add und ssh-agent wurde ein Subsystem zur Einschränkung der Weiterleitung und Nutzung von Schlüsseln implementiert, die im ssh-agent hinzugefügt wurden. Das Subsystem ermöglicht es, Regeln festzulegen, die definieren, wie und wo die Schlüssel im ssh-agent verwendet werden können. Zum Beispiel kann der folgende Befehl verwendet werden, um einen Schlüssel hinzuzufügen, der nur zur Authentifizierung bei der Verbindung von beliebigen Benutzern zu dem Host scylla.example.org, dem Benutzer perseus zu dem Host cetus.example.org und dem Benutzer medea zu dem Host charybdis.example.org, mit Umleitung über den Zwischenhost scylla.example.org, verwendet werden kann: $ ssh-add -h "perseus@cetus.example.org" \ -h "scylla.example.org" \ -h "scylla.example.org>medea@charybdis.example.org" \ ~/.ssh/id_ed25519
• In ssh und sshd wurde der hybride Algorithmus „sntrup761x25519-sha512@openssh.com“ (ECDH/x25519 + NTRU Prime) standardmäßig zur Liste der KexAlgorithms hinzugefügt, die die Reihenfolge der Schlüssel-austauschmethoden definiert und resistent gegen Angriffe mit Quantencomputern ist. In der Version OpenSSH 8.9 wurde diese Vereinbarung zwischen den Methoden ECDH und DH eingeführt, aber in der nächsten Version wird sie standardmäßig verwendet werden.
• In ssh-keygen, ssh und ssh-agent wurde die Verarbeitung von FIDO-Token-Schlüsseln, die zur Geräteverifikation verwendet werden, einschließlich biometrischer Authentifizierungsschlüssel, verbessert.
• In ssh-keygen wurde der Befehl „ssh-keygen -Y match-principals“ hinzugefügt, um Benutzernamen in der Liste der erlaubten Namen zu überprüfen.
• In ssh-add und ssh-agent wurde die Möglichkeit geschaffen, FIDO-Schlüssel, die mit einer PIN geschützt sind, zum ssh-agent hinzuzufügen (die PIN-Anfrage erscheint während der Authentifizierung).
• In ssh-keygen ist die Auswahl des Hash-Algorithmus (sha512 oder sha256) beim Erstellen der Signatur nun zulässig.
• In ssh und sshd wurde zur Leistungssteigerung das direkte Lesen von Netzwerkdaten in den Empfangspuffer implementiert, wodurch die Zwischenpufferung im Stack umgangen wird. Ebenso wurde das direkte Einfügen der empfangenen Daten in den Kanalpuffer realisiert.
• Die PubkeyAuthentication-Direktive in SSH wurde um eine erweiterte Liste unterstützter Parameter (yes|no|unbound|host-bound) ergänzt, um die Möglichkeit zu bieten, die gewünschte Protokollerweiterung auszuwählen.

In einer der kommenden Versionen ist geplant, das scp-Tool standardmäßig auf SFTP umzustellen, anstelle des veralteten SCP/RCP-Protokolls. SFTP verwendet vorhersehbarere Methoden zur Behandlung von Dateinamen und vermeidet die Verarbeitung von Glob-Mustern im Dateinamen über die Shell des Zielhosts, was Sicherheitsprobleme verursachen kann. Insbesondere bei der Verwendung von SCP und RCP entscheidet der Server, welche Dateien und Verzeichnisse an den Client gesendet werden, während der Client lediglich die Richtigkeit der zurückgegebenen Objektbezeichnungen überprüft. Dies kann, wenn der Client nicht ausreichend überprüft, zu einer Übertragung anderer, nicht angeforderter Dateinamen führen. Server Das SFTP-Protokoll hat diese Probleme nicht, unterstützt jedoch keine Auflösung spezieller Pfade wie „~/“. Um dieses Problem zu beheben, wurde in der letzten Version von OpenSSH eine neue Protokollerweiterung für den SFTP-Server vorgeschlagen, die die Auflösung der Pfade ~/ und ~user/ ermöglicht.

Quelle: opennet.ru