SSL3.0/TLS1.0 に脆弱性 12
よく考えなさる 部門より
ある Anonymous Coward 曰く、
9 月 21 〜 23 日に開催されていたセキュリティ会議 ekoparty において、SSL 3.0 および TLS 1.0 の CBC モードに対する、いくぶん実用的な盗聴方法 (BEAST) が発表された (ITmedia エンタープライズの記事より)。
この攻撃は blockwise-adaptive chosen-plaintext 攻撃 (Gregory V. Bard 氏による論文) を用いることで暗号化されたデータを復号化できるというもの (yebo blog の記事) 。今回の発表の論文は http://insecure.cl で公開されていたのだが、現在は著者からの要求により削除されている。続報は insecure.cl のサイトか Twitter アカウント @insecurechile にて、とのことなのだがスペイン語なので読解には苦労されることだろう。
この問題は TLS1.1 や 1.2 には存在しないが、実装が少ない現状では、多くの https 通信が危険な方式で暗号化していることになる。
The Tor Blog の記事の一部を訳してみたので参考にしてほしい。
攻撃手法: 基本的な背景
ここではコンピュータのことを少しは知っていて、xorがどう作用するのか分かっている前提で話をする。
初心者のために、まずブロックサイファーについて話そう。ブロックサイファーは、平文データの小片を、秘密鍵に基づいて同じサイズの暗号データに暗号化する道具だ。
実用上、一度に小さな断片だけではなく、もっと大量のデータを暗号化したい。たとえば 16 バイトブロックの (AES のような) ブロックサイファーで 256 バイトのメッセージを暗号化したいとしたらどうするか。たいていは最初に「16 バイトごとに区切ってそれぞれを暗号化しよう」と言う。昔はそういう考えでやっていた (ECB すなわち electronic codebook と呼ばれる) が、それには重大な問題が幾つかある。特に、平文に同じ 16 バイトブロックが何度も出てきたら、暗号文も同じ場所に同じブロックが出てきてしまう。
わかった、じゃあ馬鹿でもなければ ECB を使わないんだな。ところが、CBC すなわち cipher block chaining と呼ばれるモードを使う人がいる。CBC では、メッセージを暗号化する前にまず無関係なランダムブロック一つ (IV すなわち initialization vector) を作り、これを最初の暗号文ブロックとする。それから、平文の各ブロックを暗号文ブロックに暗号化していく際には、まずその平文を前の暗号文ブロックと xor するんだ (だから最初の平文ブロックは IV と xor して暗号化する。それを次の平文ブロックと xor して暗号化し、それを次の、と続ける) 。
TLS およびその前身 SSL は、多くのアプリケーションが暗号化データを送るために使っている暗号化プロトコルだ。こいつらはブロックサイファーの大部分に CBC を使う。残念なことに、TLS バージョン 1.1 より前のこいつらは、大変な間違いをしてしまった。TLS メッセージごとに毎回新しいランダム IV を使うのではなく、前のメッセージの最後の暗号文ブロックを、次の IV として使ったのだ。
どうしてこれがダメなのか。IVというのはランダムっぽく見えればいいのではない; 攻撃者が予測できないものでなくてはいけないのだ。もし君が x という IV を使うつもりであることが分かっていれば、私は君に [(NOT x) xor y] という平文ブロックで始まるメッセージを送るよう仕組むことにより、私に y を暗号化したものを送ってもらえるのだ。
これはそれほど悪い事態には見えないのだが、Wei Dai と Gregory V. Bard は、これを使って特定の暗号文が特定の平文に対応しているかどうか知る方法を見付けたのだ。攻撃者はユーザに C' xor p を暗号化させる。ここで p は原文の可能性がある平文、C' は直前の暗号文ブロックだ。その平文が当たっていると、ユーザの SSL 実装は最初にそのブロックを暗号化したときと同じ暗号文を出力してしまう。
これでもまだ大したことはなさそうに見える。この攻撃を実現するために、敵は君のインターネット接続を見張っている必要があるし、次の TLS レコードを任意の文字列で始めさせることができなければいけないし、以前に送った秘密の発言についてある程度推測できなくてはいけないし、それに対応する TLS ストリームがどこの部分なのかも推測しなければいけない。
しかしながら、暗号業界人は回避策を実装した。備えあれば憂いなし。TLS プロトコルのバージョン 1.1 では各レコードが新鮮な IV をもらうようにして、攻撃者が次のメッセージの IV を前もって知ることができないようにしたのだ。OpenSSL も修正を入れて、TLS レコードを送る際に毎回、空の TLS レコードを先に一つ送ってから、本文の入ったレコードを送るようにした。空の TLS レコードは CBC の状態を変更させるので、本文には攻撃者から予測できない新しい IV を与えるのと同じ効果が得られるのだ。
だが、こうした修正はウェブ世界にあまり広まっていない。TLS 1.1 は 2006 年に標準化されているのに広く実装・実用されていないし、OpenSSL の「空レコード」トリックも、完全準拠でない SSL 実装で動かなくなるものがあると判明したので、オフにしている人が多い (OpenSSL のマニュアルは、オフにしても「たいてい安全」だとさえ言っている) 。
当時はそれが理にかなっていると思えたのだろう。平文を推測するのは難しい: 3.4 x 10^38 通りの値があるのだ。だがよく言うように、攻撃は巧妙さを増す一方なのだ。
今回の手法の新しいところ
見たところ、Juliano Rizzo と Thai Duong には二つの点で貢献がある (誤解があれば訂正を願う; 原文を詳しく見たわけではないんだ!) 。第一に、Dai の攻撃の実に巧妙な変種を実装するシナリオを思いついたことだ。
Rizzo と Duong が提示した例そのものではなく、単純化したものを挙げよう。まず何らかの理由で、ユーザが秘密情報 (たとえば cookie) を TLS レコードごとに毎回送るものとする。さらに攻撃者はその秘密情報の直前のレコード冒頭に任意の文字数の平文を挿入させるよう仕組むことができるものとする。それで各レコードの平文は「毒|秘密」となる。「毒」というのは攻撃者の任意の情報で、「秘密」は秘密情報だ。最後の条件として、攻撃者はユーザに好きなだけたくさんのレコードを送らせることができるものとする。
ブロックの区切りの場所を決める権限があるというのは大きな利点になる。16 バイトの平文ブロック全体を毒で埋めるのではなく 15 バイトだけ埋めるとしよう。するとそのブロックは 15 バイトを攻撃者が支配し、1 バイトは秘密情報になる。
うひょ! たった 1 バイトなら可能性は 256 通りに過ぎないから、攻撃者は順番に試していって当てることができるぞ。最初の 1 バイトが当たれば次は、14 バイトの毒と 1 バイトの (ゴリ押しで当てた) 解読済み情報と 1 バイトの未解読秘密情報を送らせればいい。今回も可能性は 256 通りに過ぎないので、昔ながらの試行錯誤で十分だ。
Rizzo と Duong はこれを、攻撃者が実際にはブロックの開始位置を支配していないものの偶然 (あるいは推測) によって知る場合に拡張する方法や、その他この攻撃手法の拡張を示している。
第二の巧妙な切り口は、この攻撃をウェブブラウザに作用させる方法を実際に見付けたことにある。これは偉業と言っていい! この攻撃を実現するには、十分に制御した要求をウェブクライアントから送らせるよう仕組む方法を見付けなければいけないし、しかもそれを繰り返しやらなければいけない。見るからに大変な HTTP ハックだったろうが、それをやってのけたようだ。より詳細な情報が Eric Rescorla のブログにあるし、もちろん Juliano と Thai が論文を出せば子細に見るべきものがさらに増えるだろう。それにしてもこいつは本当に頭のいい方法だと思う。
[注意: もう一度言っておくが、上の内容には間違いがあるかもしれない; もしそうなら、朝起きてからか、それより前に直すつもりだ。私よりも詳しく知っている人はどうかダブルチェックしてほしい。]
SSL 3.0/TLS 1.0で可能な対策を考案中 (スコア:1)
https://bugzilla.mozilla.org/show_bug.cgi?id=689661 [mozilla.org]
パッチが完成したらFirefox 7.0.1とChromeのアップデートが来ると思われる。
Operaは実は11.51で対応していたらしい。
Re:SSL 3.0/TLS 1.0で可能な対策を考案中 (スコア:2)
iida
Re:SSL 3.0/TLS 1.0で可能な対策を考案中 (スコア:4, 興味深い)
リンク間違えた。正しくはこっち
https://bugzilla.mozilla.org/show_bug.cgi?id=665814 [mozilla.org]
> OpenSSL [openssl.org] 0.9.6dみたいに、「空平文を先頭に入れる」という対応では、ダメなんですかね?
それだと接続できないサーバが現に存在していて、OpenSSLの当該オプションも無効にするように促されていたりする。
そこで0バイトじゃなくて1バイトだけ平文を入れればいいんじゃね? というアイデアに基づいてパッチを開発中。
ということも上記リンク先で説明されている。
Re: (スコア:0)
あれ？09/28付けでFirefox本体は影響受けないって公言されてたぞ？？？
※アドオンは影響を受ける
http://mozilla.jp/blog/ [mozilla.jp]
# NSS自体の穴はかわせる仕組みってことかな
# タブ・ウィンドウ間やクロスサイトでのクッキー読み書き禁止とか
# NSS部分の入れ替えというアップデートはあると思うけど
# ニュアンスはちょっと違うよね
Re:SSL 3.0/TLS 1.0で可能な対策を考案中 (スコア:2, 参考になる)
簡単に言うと
・現時点でもFirefox本体は影響をうけるようなNSSの使い方をしていない
・どんな使い方をしても安全なように(将来の新しいプロトコルでうっかり脆弱性を作り込む心配がないように)NSS自体の改善を提案中
ということ。ただしJavaのURLConnectionはFirefox本体のNSSと関係なく完全に独自に通信しているので、Oracleが修正してくれない限り救えない。
Re:SSL 3.0/TLS 1.0で可能な対策を考案中 (スコア:1)
うんだから元コメへ突っ込みしたのですよ
これじゃFirefox本体も影響をうけるようにしか読めないもの。
IEについては触れていないけど影響を受ける。
現状、影響を受けないのは、
OperaとアドオンなしFirefoxってことで。
# アドオンなしFirefoxは現実的じゃないから
# Firefoxも未対応とみなしてもいいけど
# 補足は必要でしょ？＋モデついてるならなおのこおと。
Re: (スコア:0)
Firefoxでは影響を受けるのはOracleのJavaだけなんじゃないの？
Java Pluginを導入してないFirefoxなら普通に実用的ですけど・・・
通りでMSのアドバイザリしか対処が無い訳だ (スコア:1)
Win7/2008R2上のIEはTLS1.1/1.2を実装しているが、標準はオフ
Vista以前のIE,Firefox,ChromeはTLS1.0までしか実装してない？
セキュリティに優れると言っておきながらこのざまなんだね・・・
何故TLS1.1/1.2実装してなかったのだろう
Re:通りでMSのアドバイザリしか対処が無い訳だ (スコア:1)
なぜって、XP: 2002年、Vista: 2006年、TLS 1.1: 2006年で、そりゃ実装する暇もないでしょう。もっとも、たしかにTLS 1.1/1.2くらいはXPやVistaでもアップデートで提供してほしいですね。
Re:通りでMSのアドバイザリしか対処が無い訳だ (スコア:1)
確認してみたけど
IE9 for Win7 TLS 1.1/1.2 ある
Firefox 7.0.1 TLS 1.1/1.2 ない
Chrome 14.0.835.186 TLS 1.1/1.2 ない
だねぇ。
過敏である必要はないけど、いっそセキュリティが必要な通信はIEだけのほうがいいか
# インターネットオプションは SSL 2.0/3.0 TLS 1.0をオフ、TLS 1.1/1.2をオンにしました、普段はFirefoxだし。
せめて実装しておいてくれよ。いや実装はあるかもしれんが表オプションもさ。
M-FalconSky (暑いか寒い)
考え中なのだけど (スコア:0)
攻略完了後に、接続が再利用される形で攻撃対象サイトに誘導することはできないのかな？
(たとえば、サブドメインとワイルドカード証明書が絡んだ時とか…)
サーバサイドの対策は？ (スコア:0)
できるだけ早くクライアントでTLS1.1/1.2に対応してもらうのも大事だけど
今サーバにできることって何？
GoogleはRC4(stream cipher)使ってるみたいだけど問題ないの？
http://isc.sans.edu/diary.html?storyid=11635 [sans.edu]