[タレコミ] SSH通信において（低確率ながら）一部データが漏えいする可能性

kirara(397) 曰く、

JVNの記事によれば、暗号通信プロトコル「SSH」で使用される通信方式の一部に対する攻撃方法が報告されたらしい。低確率ながら、この攻撃が成立した場合、ひとつの暗号化ブロックから 32ビットの平文を取り出すことが可能とのこと。
対策として、CBC（Cipher Block Chaining）モードではなく CTR（CounTR）モードを使用することが挙げられている。

また、セキュリティホール memoの記事によれば、

• 少なくとも OpenSSH 4.7p1 に欠陥
• 2^-18 という極めて低い確率ではあるが、任意の暗号化ブロックから 32bit の平文を取り出すことができる
• この手法の変形版を使用すると、2^-14 の確率で 14bit の平文を取り出すことができる
• 他の SSH 実装での状況は不明 (だが同様か?!)
• OpenSSH の場合、OpenSSH 3.7 以降で CTR モード (aes128-ctr, aes192-ctr, aes256-ctr) を利用できる
• OpenSSL 0.9.8e と共に使用すると不具合が発生するため、OpenSSH 4.6p1 以降 + OpenSSL 0.9.8e の場合には aes256-ctr および aes192-ctr は利用できない
• PuTTY の場合はデフォルトで CTR モードが優先されるようだ

といった情報が提供されている。

比較的信頼性の高いと思われていたSSHでこのような報告が上がるとドキッとしてしまう。皆様の環境においては影響あるだろうか？

下手な鉄砲

[deraok (37011)]

>他の SSH 実装での状況は不明 (だが同様か?!)
(aes128-)cbc自体に脆弱性ということであれば同様なんでしょうね．
OpenSSHは，
*aes128-cbcがデフォルトの設定であること
*RFC 4251準拠=エラー時に自動で再接続することから，2^-18の確率でも数打ちゃ当たる
ってとこで特にまずいってことではないでしょうか．

#とりあえずうちのsshd_config確認したら，*-cbcはコメントアウトされてたので一安心かな．

Re:下手な鉄砲

[Anonymous Coward]

ssh_configでしょうか？あのコメントアウトは、デフォルト設定の明示だったかと。

Re:

[Anonymous Coward]

アタックを防ぐんだからsshd_configでは？
> SSHサーバのsshd_configで許可された暗号方式の内、
> SSHクライアントのssh_configで最も優先度が高いものが選ばれる。
のでsshd_configでcbc方式をコメントアウトしておけば、
悪意のあるクライアントがこのアタックを仕掛けることはできません。

ssh_config でも sshd_config でもいい

[okky (2487)]

Ciphers リストの中から cbc 方式を外したものを明示的に作っておけばオッケー。

.

ついでに言うと、cbc方式にしたからといって「赤の他人がノーヒントで login できる確率があがる」という意味ではない。なので

悪意のあるクライアントがこのアタックを仕掛けることはできません。

というこれは、今回の事象とは全然違う。

今回の問題は、あくまでも「暗号化されているパケット」を盗み見している第三者が、2**(-18) の確率で 32bit の平文を得ることができる…つまり「暗号化せずに通信している」状態に近づいている、という意味。(差分は大雑把に14bit分ですので 128bitの共通鍵が 114bit分の強度しか持たなくなったと思えば。多分「2**(-14)の確率で 14bitの平文」という『14bit』はここから来ているのではないかと)。

.

…あえて例を出すと…

今回の脆弱性は、「自宅 ssh串 を使っていろいろやっていたのに、この脆弱性のせいでネットワーク管理者に通信内容がばれてしまいました」的な現象を起こす可能性がある、と言うこと。

このACが言っているのは「自宅にssh串を立てているが、第三者がノーヒントでssh串にログインされる危険性が増えた」と言っている。今回の脆弱性に関しては、この心配はしなくていい。

--
fjの教祖様

Re:

[Anonymous Coward]

コメントアウトされているから、デフォルトの*aes128-cbcが使われてしまうという事ではないでしょうか？

CTRモード

[Anonymous Coward]

CTRもちょっと実装のヘマをしただけで脆弱になるぞ、というのがこの辺のRFC [faqs.org]にあったりしますけどね。
ただCTRは並列処理化が容易なので超速にすることができるよ、というのがHigh Performance SSH/SCP [psc.edu]。
以上、昔ちょっと調べた成果でした

Poderosa の場合

[kamiyan (10895)]

設定項目がないのでログで確認したところ、CBCしかサポートしていませんでした。
Windowsマシンでは長らくPoderosa使ってましたが、今後の更新もなさそうだしPuTTYに鞍替えしようかな。

Poderosaイベントログより引用:
Transmitted: kex_algorithm=diffie-hellman-group1-sha1; server_host_key_algorithms=ssh-dss,ssh-rsa; encryption_algorithms_client_to_server=aes128-cbc,blowfish-cbc,3des-cbc; encryption_algorithms_server_to_client=aes128-cbc,blowfish-cbc,3des-cbc; mac_algorithms_client_to_server=hmac-sha1; mac_algorithms_server_to_client=hmac-sha1

Re:

[Anonymous Coward]

UTF-8 TeraTerm Pro with TTSSH2 [osdn.jp]もおすすめ。

Re:Poderosa の場合

[Nyaboo (33313)]

オフトピですが、Tera Termに改名してますよ。
http://osdn.jp/projects/ttssh2/releases/31708/changelog [osdn.jp]

[TeraTerm]
2008.6.25 (Ver 4.59)
-パッケージ名を「UTF-8 TeraTerm Pro with TTSSH2」から「Tera Term」に改名した。
アンインストール・新規インストールでの導入をおすすめします。

--
Nyaboo

Re:Poderosa の場合

[doda (31157)]

今はTera Termに名前が変わっています。

ちなみに、Tera Term(ttssh2)もCTRモードに対応していません。
# 現在、鋭意対応中。
http://ttssh2.osdn.jp/snapshot/teraterm-4.61-Alpha3.exe [osdn.jp]

Re:

[Anonymous Coward]

Poderosa はタブがあったりするのが売りでないの？
Cygwin の ssh 使えばそれでよいような。

Re:Poderosa の場合

[kamiyan (10895)]

そういえば自分もたまに Poderosa の中に Cygterm 開いて、ssh-agent + ssh で接続するようなこともしてました。
(どちらかというと ssh-agent + scp/rsync でのファイル転送目的ですが)
それでいいか。

信頼性が高い？

[Anonymous Coward]

>比較的信頼性の高いと思われていたSSHでこのような報告が上がるとドキッとしてしまう。皆様の環境においては影響あるだろうか？

SSHも一時期は頻繁にセキュリティパッチを出ていた。
そんな記憶があるものにとっては、信頼性が高い、と書かれると首をかしげてしまうな。

一つのセキュリティ技術にすべてを預けるのは危険、そんな基本を忘れた頃が一番危険。

----------
自分への自戒をこめて

君も私もくらっかー？

[biiko (32223)]

>この手法の変形版を使用すると、2^-14 の確率で 14bit の平文を取り出すことができる
どんな14bitでも，2^-14 の確率でヒットするような…？

Re:君も私もくらっかー？

[n_ayase (36873)]

ブルートフォースと違って、「ヒットしたことが判る」ということなのでしょうかね？

＃ ブルートフォースだと、パスワードなど白黒はっきりするモノ以外は
＃ たとえ正解でもそう確証できるわけではない、ですよね？

--
神社でC#.NET

Re:

[Anonymous Coward]

2^14個のうちどれが正解なのか確実に分かるのが2^14回に一回、という事ではないでしょうか。

arcfour

[Anonymous Coward]

演算量が少なく、結果として古いPCでも速度が稼げるため、 arcfour(RC4)を優先して使っていますが、これも該当するのでしょうか？

Re:arcfour

[Anonymous Coward]

憶測です。詳しい人の補足をお願いします。

CPNIのアドバイザリにもあまり詳しい情報がないので断言できないのですが、資料を読む限りでは、おそらくCipher Block Chaining(CBC)モードとブロック暗号を組み合わせたときに、攻撃が可能になってしまうと思われます。
Arcfourはストリーム暗号であり、CBCのような仕組みを必要としません。したがって、「CBCモードとブロック暗号の組み合わせ」が原因なのであれば、Arcfourは今回の影響を受けないと考えられます。

Re:arcfour

[Anonymous Coward]

先ほど[e-mail]に流れた情報によりますと、OpenSSHでは、

* 速やかにパッチを提供することは考えていない。
(原文: At present we do not feel that this issue is serious enough to make an emergency release.)

* CPNIが充分な情報をだしてくれないのでよくわからない
(CPNI's unwillingness to share necessary information, we are unable to properly assess its impact.)

* 2002年に発表されている下記のものをベースにしているかも
http://www.cs.washington.edu/homes/yoshi/papers/TISSEC04/

* 2^-14という確率はひくく、多くのユーザにとっては心配するほどではないだろう

* コネクションを閉じるアタックについては、攻撃者はコネクションの切断を成功させるためには23768回挑戦する必要がある
(An attacker would expect around 32768 connection-killing attempts before they are likely to succeed.)

* 現時点てはAESのCTRモード, ストリーム暗号のARCFOURは安全なので、sshd_configとssh_configは

Ciphers aes128-ctr,aes256-ctr,arcfour256,arcfour,aes128-cbc,aes256-cbc

とするのがおすすめ。
(AES CTR mode and arcfour ciphers are not vulnerable to this attack at all.)

* 今後のリリースではCTRをデフォルトにし、別の暗号利用モードを追加するかもしれない。
(A future version of OpenSSH may make CTR mode ciphers the default and/or implement other countermeasures)

ということのようです。

Re:arcfour

[kjm (1606)]

Plaintext Recovery Attack Against SSH [ssh.com] によると、SSH Tectia では CryptiCore または Arcfour を使用することでこの欠陥を回避できるそうです。 ですので、OpenSSH でも Arcfour を利用すれば回避できると思います。

追い込み漁

[Anonymous Coward]

これが契機でみんなCTRにしたとして、CTRにゼロデイな穴が隠れてたら(そして知ってる悪い人がもし存在したら)
入れ食いですね。

Re:SSHを信用できない

[ksiroi (24990)]

sshとウェブサイトってあんまり関係ないんじゃ・・・・
// ssl?