私は最近 OpenSSHクライアントの重大なバグ ( CVE-2016-0777およびCVE-2016-0778 )について聞いたことがあります。正しく理解していれば、リモートでコードが実行される可能性があります。アクティブな中間者がそれを利用するのはどれほど難しいでしょうか?
Steve Setherが言ったように、これは man-in-the-middle攻撃 ではありません。
ページによると:
SSHローミングを使用すると、SSH接続が予期せず中断した場合でも、サーバーがサポートしていれば、クライアントが後で再開することができます。 OpenSSHサーバーはローミングをサポートしていませんが、OpenSSHクライアントは(ドキュメント化されていなくても)ローミングをサポートしており、デフォルトで有効になっています。
手始めに、この機能はOpenSSHではデフォルトで有効になっています。さらに悪いことに、それはssh_config(5)
のマニュアルページに記載されていません。
これは2つのエクスプロイトであることに注意してください。
バッファオーバーフロー攻撃については、ProxyCommandがあり、ForwardAgentまたはForwardX11が有効になっている場合に、特定の条件下でのみ脆弱であることに注意してください。これらはデフォルト以外のオプションであるため、ほとんどの場合は悪用される可能性はありませんが、可能です。
バッファオーバーフロー攻撃が成功した場合は、SSHクライアントからアクセス可能なすべてのものが侵害されていると想定します。
Qualys Analysis と読みます。この文書では、この攻撃について、私を含むほとんどの人よりはるかに詳しく説明します。
リモートでコードが実行される可能性がある
リモートでのコード実行はありません。マークによって片付けられたため、中間者はいなかった。既にリンクされているように、すべてが Qualys分析 で説明されています。
脆弱なのは、クライアントのローミング機能の実装です。接続が中断された場合、クライアントは送信しないバイトのバッファを格納します。脆弱で巧妙に作成されたサーバーは、クライアントがバッファ内にある以上の再送信を強制する可能性があるため、実際にいくつかのアドレスに格納されている場合、可能性がありますではありません通常の場合です)。
分析は特定のバージョン(openssh-6.4)で提示されます。これは、今日ほとんど使用されておらず、ほとんどのユースケースは現在使用されているものに直接適用できません。バージョン。また、メモリのゼロ化が期待どおりに機能しなかったBSDシステムに固有の問題もあります。周りにある現在のシステムでは、なんとかキーを取得できませんでした。
最大の問題は、そのようなことさえあったものであり、文書化されていない機能、そのような形で脆弱でした。そして、それは非常に長い間存在し(2004年に導入)、デフォルトでオンでした。これは過去に誤用された可能性がありますが、ユーザーの知識がなければ(セッションがインタラクティブであった場合)。あなたが見るなら
[connection suspended, press return to resume]
少し疑わしいと思います。