パスワードを忘れた? アカウント作成
40686 story
暗号

SSH通信において低確率ながら一部データが漏えいする可能性 23

ストーリー by hylom
可能性は低いとはいえ注意が必要、 部門より

kirara(397) 曰く

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

また、セキュリティホール memoの記事およびCPNIのアドバイザリによれば、

  • 少なくとも 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でこのような報告が上がるとドキッとしてしまう。皆様の環境においては影響あるだろうか?

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 下手な鉄砲 (スコア:2, 参考になる)

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

    #とりあえずうちのsshd_config確認したら,*-cbcはコメントアウトされてたので一安心かな.
    • Re:下手な鉄砲 (スコア:1, 参考になる)

      by Anonymous Coward on 2008年11月18日 15時31分 (#1457621)
      ssh_configでしょうか?あのコメントアウトは、デフォルト設定の明示だったかと。
      親コメント
      • by Anonymous Coward
        アタックを防ぐんだからsshd_configでは?
        > SSHサーバのsshd_configで許可された暗号方式の内、
        > SSHクライアントのssh_configで最も優先度が高いものが選ばれる。
        のでsshd_configでcbc方式をコメントアウトしておけば、
        悪意のあるクライアントがこのアタックを仕掛けることはできません。
        • Ciphers リストの中から cbc 方式を外したものを明示的に作っておけばオッケー。

          .

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

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

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

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

          .

          …あえて例を出すと…

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

          このACが言っているのは「自宅にssh串を立てているが、第三者がノーヒントでssh串にログインされる危険性が増えた」と言っている。今回の脆弱性に関しては、この心配はしなくていい。
          --
          fjの教祖様
          親コメント
    • by Anonymous Coward
      コメントアウトされているから、デフォルトの*aes128-cbcが使われてしまうという事ではないでしょうか?
  • CTRモード (スコア:2, 参考になる)

    by Anonymous Coward on 2008年11月18日 15時33分 (#1457626)
    CTRもちょっと実装のヘマをしただけで脆弱になるぞ、というのがこの辺のRFC [faqs.org]にあったりしますけどね。
    ただCTRは並列処理化が容易なので超速にすることができるよ、というのがHigh Performance SSH/SCP [psc.edu]。
    以上、昔ちょっと調べた成果でした
  • Poderosa の場合 (スコア:2, 参考になる)

    by kamiyan (10895) on 2008年11月18日 17時39分 (#1457742) ホームページ
    設定項目がないのでログで確認したところ、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
  • 信頼性が高い? (スコア:2, すばらしい洞察)

    by Anonymous Coward on 2008年11月18日 18時38分 (#1457786)
    >比較的信頼性の高いと思われていたSSHでこのような報告が上がるとドキッとしてしまう。皆様の環境においては影響あるだろうか?

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

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

    ----------
    自分への自戒をこめて
  • by biiko (32223) on 2008年11月18日 14時07分 (#1457540)
    >この手法の変形版を使用すると、2-14 の確率で 14bit の平文を取り出すことができる
    どんな14bitでも,2-14 の確率でヒットするような…?
    • ブルートフォースと違って、「ヒットしたことが判る」ということなのでしょうかね?

      # ブルートフォースだと、パスワードなど白黒はっきりするモノ以外は
      # たとえ正解でもそう確証できるわけではない、ですよね?
      --
      神社でC#.NET
      親コメント
    • by Anonymous Coward
      2^14個のうちどれが正解なのか確実に分かるのが2^14回に一回、という事ではないでしょうか。
  • by Anonymous Coward on 2008年11月18日 15時59分 (#1457647)
    演算量が少なく、結果として古いPCでも速度が稼げるため、 arcfour(RC4)を優先して使っていますが、これも該当するのでしょうか?
    • Re:arcfour (スコア:1, 興味深い)

      by Anonymous Coward on 2008年11月18日 16時34分 (#1457685)
      憶測です。詳しい人の補足をお願いします。

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

        by Anonymous Coward on 2008年11月22日 1時45分 (#1460191)
        先ほどannounce@openbsd.orgに流れた情報によりますと、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)

        ということのようです。
        親コメント
    • by kjm (1606) on 2008年11月19日 13時27分 (#1458217) ホームページ
      Plaintext Recovery Attack Against SSH [ssh.com] によると、SSH Tectia では CryptiCore または Arcfour を使用することでこの欠陥を回避できるそうです。 ですので、OpenSSH でも Arcfour を利用すれば回避できると思います。
      親コメント
  • by Anonymous Coward on 2008年11月19日 13時42分 (#1458233)
    これが契機でみんなCTRにしたとして、CTRにゼロデイな穴が隠れてたら(そして知ってる悪い人がもし存在したら)
    入れ食いですね。
typodupeerror

私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson

読み込み中...