Die Veröffentlichung von OpenSSH 8.8, einer offenen Implementierung von Client und Server für die Arbeit mit den Protokollen SSH 2.0 und SFTP, wurde bekannt gegeben. Die Ausgabe ist bemerkenswert, da die Verwendung von digitalen Signaturen basierend auf RSA-Schlüsseln mit dem SHA-1-Hash („ssh-rsa“) standardmäßig deaktiviert wurde.
Die Einstellung der Unterstützung für „ssh-rsa“ ist auf die erhöhten Effizienz von Kollisionsangriffen mit festgelegtem Präfix zurückzuführen (die Kosten für die Erzeugung einer Kollision werden auf etwa 50.000 Dollar geschätzt). Um zu überprüfen, ob ssh-rsa in Ihren Systemen verwendet wird, können Sie versuchen, eine Verbindung über ssh mit der Option „-oHostKeyAlgorithms=-ssh-rsa“ herzustellen. Die Unterstützung für RSA-Signaturen mit den Hashes SHA-256 und SHA-512 (rsa-sha2-256/512), die seit OpenSSH 7.2 unterstützt werden, bleibt unverändert.
In den meisten Fällen erfordert die Einstellung der Unterstützung für „ssh-rsa“ keine manuellen Aktionen von den Benutzern, da in OpenSSH zuvor standardmäßig die Einstellung UpdateHostKeys aktiviert war, die eine automatische Umstellung der Clients auf sicherere Algorithmen durchführte. Für die Migration wird die Protokollerweiterung „hostkeys@openssh.com“ verwendet, die es ermöglicht zu einem Server nach der Authentifizierung den Client über alle verfügbaren Hostschlüssel zu informieren. Bei Verbindungen zu Hosts mit sehr alten Versionen von OpenSSH kann auf der Client-Seite selektiv die Verwendung von „ssh-rsa“-Signaturen wiederhergestellt werden, indem Folgendes in die ~/.ssh/config hinzugefügt wird: Host alter_host_name HostkeyAlgorithms +ssh-rsa PubkeyAcceptedAlgorithms +ssh-rsa
In der neuen Version wurde auch ein Sicherheitsproblem behoben, das dadurch verursacht wurde, dass im sshd, beginnend mit der Veröffentlichung von OpenSSH 6.2, die Initialisierung der Benutzergruppe bei der Ausführung von Befehlen, die in den Direktiven AuthorizedKeysCommand und AuthorizedPrincipalsCommand festgelegt sind, fehlerhaft durchgeführt wurde. Diese Direktiven sollten die Ausführung von Befehlen unter einem anderen Benutzer ermöglichen, aber in der Praxis vererbten sie die Gruppenzugehörigkeit, die bei der Ausführung von sshd verwendet wurde. Potenziell konnte ein solcher Prozess bei bestimmten Systemkonfigurationen zusätzliche Privilegien im System erlangen.
Im Hinweis zum neuen Release wurde auch eine Warnung veröffentlicht, dass die Standardnutzung des SCP-Tools auf SFTP anstelle des veralteten SCP/RCP-Protokolls umgestellt werden soll. SFTP verwendet vorhersehbarere Methoden zur Handhabung von Bezeichnungen und nutzt keine glob-Musterverarbeitung in Dateinamen über die Shell auf dem anderen Host, was Sicherheitsprobleme verursacht. Insbesondere bei der Anwendung von SCP und RCP nimmt es Entscheidungen darüber, welche Dateien und Verzeichnisse an den Client gesendet werden, und der Client überprüft lediglich die Korrektheit der zurückgegebenen Objektbezeichnungen, was in Ermangelung angemessener Prüfungen auf der Client-Seite dem Server erlaubt, andere Dateinamen zu übermitteln, die von den angeforderten abweichen. Das SFTP-Protokoll hat diese Probleme nicht, unterstützt jedoch nicht die Auflösung von Spezialpfaden wie „~/“. Um diesen Unterschied zu beseitigen, wurde in der vorherigen Version von OpenSSH eine neue Erweiterung des SFTP-Protokolls zur Auflösung der Pfade ~/ und ~user/ vorgeschlagen. Server Die Veröffentlichung von OpenSSH 8.8, einer offenen Implementierung des Clients und Servers für die Arbeit mit den Protokollen SSH 2.0 und SFTP.
Quelle: opennet.ru
