アカウント名:
パスワード:
悪意のあるクライアントがこのアタックを仕掛けることはできません。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
下手な鉄砲 (スコア:2, 参考になる)
(aes128-)cbc自体に脆弱性ということであれば同様なんでしょうね．
OpenSSHは，
*aes128-cbcがデフォルトの設定であること
*RFC 4251準拠=エラー時に自動で再接続することから，2^-18の確率でも数打ちゃ当たる
ってとこで特にまずいってことではないでしょうか．
#とりあえずうちのsshd_config確認したら，*-cbcはコメントアウトされてたので一安心かな．
Re:下手な鉄砲 (スコア:1, 参考になる)
Re: (スコア:0)
> SSHサーバのsshd_configで許可された暗号方式の内、
> SSHクライアントのssh_configで最も優先度が高いものが選ばれる。
のでsshd_configでcbc方式をコメントアウトしておけば、
悪意のあるクライアントがこのアタックを仕掛けることはできません。
ssh_config でも sshd_config でもいい (スコア:3, 興味深い)
.
ついでに言うと、cbc方式にしたからといって「赤の他人がノーヒントで login できる確率があがる」という意味ではない。なので
というこれは、今回の事象とは全然違う。
今回の問題は、あくまでも「暗号化されているパケット」を盗み見している第三者が、2**(-18) の確率で 32bit の平文を得ることができる…つまり「暗号化せずに通信している」状態に近づいている、という意味。(差分は大雑把に14bit分ですので 128bitの共通鍵が 114bit分の強度しか持たなくなったと思えば。多分「2**(-14)の確率で 14bitの平文」という『14bit』はここから来ているのではないかと)。
.
…あえて例を出すと…
今回の脆弱性は、「自宅 ssh串 を使っていろいろやっていたのに、この脆弱性のせいでネットワーク管理者に通信内容がばれてしまいました」的な現象を起こす可能性がある、と言うこと。
このACが言っているのは「自宅にssh串を立てているが、第三者がノーヒントでssh串にログインされる危険性が増えた」と言っている。今回の脆弱性に関しては、この心配はしなくていい。
fjの教祖様
Re: (スコア:0)