これらの欠陥が悪用されると、攻撃者は機密情報に不正にアクセスしたり、一般的に問題を引き起こしたりする可能性があります
クラウドセキュリティを専門とするテクノロジー企業であるQualysは最近、OpenSSH 9.1の脆弱性を利用して、mallocとno-double保護を回避し、コード転送を開始する方法を発見したと発表した。
これまでのところ、この脆弱性は「理論上の」ものに過ぎず、実際に動作するエクスプロイトを作成する可能性は低いと判断されている。しかし、実際に動作するエクスプロイトを作成できるかどうかは、依然として大きな疑問点である。
脆弱性に関して、malloc のダブルフリーおよび解放後使用の保護を回避するトリックは、options.kex_algorithms によって占有されていたメモリが解放されたらすぐに再割り当てすることであると述べられています。
malloc の観点からは、すでに解放されているメモリを解放、読み取り、または書き込みしようとする試みは行われません。 ただし、sshd のポイントからは、XNUMX つの異なるオブジェクトへの XNUMX つの異なるポインターが同じメモリ チャンクを参照し、XNUMX つのオブジェクトへの書き込みが他のオブジェクトを上書きするため、エイリアシング攻撃が発生します。
これにより、可能性の世界が開かれます。
Debian ブックワーム (glibc コードを使用) の調査を開始しました。
malloc) でしたが、最終的に OpenBSD 7.2 に切り替えました。
malloc (非常に防御的なプログラミングにもかかわらず) には、次の XNUMX つの機能があります。
この特定の無料のダブル バグを特に興味深いものにします。
この脆弱性は、認証前段階でメモリ領域が二重に解放されることに起因します。この脆弱性を再現するには、SSHクライアントのバナーを「SSH-2.0-FuTTYSH_9.1p1」（または別の古いSSHクライアント）に変更し、「SSH_BUG_CURVE25519PAD」および「SSH_OLD_DHGEX」フラグの設定を有効にするだけです。これらのフラグを設定すると、「options.kex_algorithms」バッファのメモリが二重に解放されます。
脆弱性を悪用する際、Qualysの研究者らは、次に実行される命令へのポインタを含むプロセッサレジスタ「% rip」の制御権を取得することに成功した。彼らが開発したエクスプロイト手法により、OpenSSH 9.1にデフォルトで付属する、アップデートされていないOpenBSD 7.2環境において、sshdプロセスのアドレス空間内の任意の場所に制御を移すことが可能になった。
クイック アップデート: 「裂け目」を任意に制御することができました このバグを介して (つまり、sshd の好きな場所にジャンプできます) アドレス空間) OpenBSD 7.2 のパッチを適用していないインストール (実行中)
デフォルトでは OpenSSH 9.1)。 これは決して物語の終わりではありません: この eステップ 1 だけでは、malloc と double ガードをスキップします。次のステップは、実現可能かどうかは別として、以下の通りである。
– ステップ 2、ASLR、NX、ROP にもかかわらず、任意のコードを実行する
保護 (これには、情報の漏えいが必要になる可能性があります。
同じエラーまたは二次エラーによる);– ステップ 3、sshd サンドボックスをエスケープする (マイナーなバグを介して、
特権のある親プロセスまたは縮小されたカーネル攻撃で
水面）。
提案されたプロトタイプは攻撃の第一段階の実装に過ぎないことが指摘されている。実際に機能するエクスプロイトを作成するには、ASLR、NX、ROPの保護メカニズムを回避し、サンドボックスの隔離状態から抜け出す必要があるが、これは現実的ではない。
ASLR、NX、および ROP をバイパスする問題を解決するには、アドレス情報を取得する必要があります。これは、情報漏えいにつながる別の脆弱性を特定することで実現できます。 特権を持つ親またはカーネル プロセスのバグは、サンドボックスから抜け出すのに役立ちます。
この脆弱性は、次のように機能することが言及されています。
- -まず、compat_kex_proposal() で options.kex_algorithms を解放し、ssh クライアントが古い「FuTTY」クライアントであるふりをします。
- -次に、options.kex_algorithms によって占められていたフラグメントが再割り当てされ、サイズが 264 バイトの構造 EVP_AES_KEY が使用され、鍵交換フェーズで「aes128-ctr」暗号が選択されます。 この再割り当ては、約 1/32 の確率で発生します。
- – XNUMX 番目に、(再び) options.kex_algorithms によって占有されていた (そして現在は EVP_AES_KEY 構造体によって占有されている) チャンクを kex_assemble_names() で (mm_getpwnamallow() を介して) 解放します。 これは、チャンクの最初のバイトが '+'、'-'、または '^' である場合にのみ発生します (そうでない場合、 kex_assembly_names() はエラーを返し、fatal_fr() が呼び出されます)。
- – 300 番目に、options.kex_algorithms によって占有されていたチャンク (および現在も EVP_AES_KEY 構造として参照されている) が、2 'A' バイト文字列、「authctxt->user」または「authctxt ->style」で再割り当てされます。認証フェーズ。 EVP_AES_KEY 構造全体を「A」バイトで効果的に上書きするこの再割り当ては、約 32/XNUMX の確率で発生します。
- – 最後に、sshd が EVP_Cipher() を呼び出すと、0x4141414141414141 にジャンプします。EVP_AES_KEY 構造には、「A」バイトによって上書きされ、CRYPTO_ctr128_encrypt_ctr32() (EVP_Cipher() 経由) によって呼び出される関数ポインターが含まれているためです。
最後に、さらに詳しく知りたい場合は、以下のリンクから詳細をご確認いただけます。