8.9 か月の開発を経て、SSH 2.0 および SFTP プロトコル上で動作するクライアントとサーバーのオープン実装である OpenSSH XNUMX がリリースされました。 sshd の新しいバージョンでは、認証されていないアクセスを許可する可能性がある脆弱性が修正されています。この問題は認証コード内の整数オーバーフローによって引き起こされますが、コード内の他の論理エラーと組み合わせてのみ悪用される可能性があります。
現在の形式では、権限分離トラッキング コードで実行される個別のチェックによってその発現がブロックされるため、権限分離モードが有効になっている場合、この脆弱性を悪用することはできません。特権分離モードは、2002 年の OpenSSH 3.2.2 以降デフォルトで有効になっており、7.5 年に公開された OpenSSH 2017 のリリース以降は必須となっています。さらに、リリース 6.5 (2014) 以降の OpenSSH のポータブル バージョンでは、この脆弱性は整数オーバーフロー保護フラグを含めてコンパイルすることによってブロックされます。
その他の変更:
- sshd の OpenSSH のポータブル バージョンでは、MD5 アルゴリズムを使用したパスワードのハッシュのネイティブ サポートが削除されました (libxcrypt などの外部ライブラリとのリンクが返されるようになります)。
- ssh、sshd、ssh-add、および ssh-agent は、ssh-agent に追加されたキーの転送と使用を制限するサブシステムを実装します。サブシステムを使用すると、ssh-agent でキーをどこでどのように使用できるかを決定するルールを設定できます。たとえば、ホスト scylla.example.org に接続するユーザーの認証にのみ使用できるキーを追加するには、ユーザー perseus をホスト cetus.example.org に、ユーザー medea をホスト charybdis.example.org に追加します。中間ホスト scylla.example.org を介したリダイレクトでは、次のコマンドを使用できます: $ ssh-add -h "[メール保護]" \ -h "scylla.example.org" \ -h "scylla.example.org>[メール保護]\ ~/.ssh/id_ed25519
- ssh および sshd では、ハイブリッド アルゴリズムがデフォルトで KexAlgorithms リストに追加されており、これにより鍵交換方式が選択される順序が決まります。[メール保護]"(ECDH/x25519 + NTRU Prime)、量子コンピューターでの選択に耐性があります。 OpenSSH 8.9 では、このネゴシエーション メソッドが ECDH メソッドと DH メソッドの間に追加されましたが、次のリリースではデフォルトで有効になる予定です。
- ssh-keygen、ssh、および ssh-agent では、生体認証用のキーを含む、デバイス検証に使用される FIDO トークン キーの処理が改善されました。
- allowednamelist ファイル内のユーザー名をチェックするための「ssh-keygen -Y match-principals」コマンドを ssh-keygen に追加しました。
- ssh-add および ssh-agent は、PIN コードで保護された FIDO キーを ssh-agent に追加する機能を提供します (PIN 要求は認証時に表示されます)。
- ssh-keygen では、署名生成時にハッシュ アルゴリズム (sha512 または sha256) を選択できます。
- ssh および sshd では、パフォーマンスを向上させるために、スタック上の中間バッファリングをバイパスし、ネットワーク データが受信パケットのバッファに直接読み込まれます。受信データのチャネル バッファへの直接配置も同様の方法で実装されます。
- ssh では、PubkeyAuthentication ディレクティブによってサポートされるパラメーターのリスト (yes|no|unbound|host-bound) が拡張され、使用するプロトコル拡張を選択できるようになりました。
将来のリリースでは、従来の SCP/RCP プロトコルの代わりに SFTP を使用するように scp ユーティリティのデフォルトを変更する予定です。 SFTP は、より予測可能な名前処理方法を使用し、セキュリティ上の問題を引き起こす、他のホスト側のファイル名の glob パターンのシェル処理を使用しません。特に、SCP と RCP を使用する場合、サーバーはクライアントに送信するファイルとディレクトリを決定し、クライアントは返されたオブジェクト名の正確性のみをチェックします。これにより、クライアント側で適切なチェックが行われないと、サーバーは、要求されたものとは異なる他のファイル名を転送します。 SFTP プロトコルにはこれらの問題はありませんが、「~/」などの特殊なパスの展開はサポートされていません。この違いに対処するために、OpenSSH の以前のリリースでは、SFTP サーバーの実装において ~/ および ~user/ パスを拡張するための SFTP プロトコルの新しい拡張が提案されました。
出所： オープンネット.ru