★☆★JNSAメールマガジン 第37号 2014.6.13.☆★☆
先週木曜夜にOpenSSLにおける新しい脆弱性の情報が飛び込んできました*1。今頃 Heartbleed Bug の報道が新しく取り上げられているのかと勘違いした人も居たほど「またかぁ(ハァ)」というのが正直な現場の声ではないでしょうか。4月に発覚したHeartbleedの件では、実際に国内でも被害が報告されたこともあり、かなり大々的に報道されました。一方で先週発覚した脆弱性は、サーバ・クライアントともにOpenSSLのライブラリを利用していること、攻撃が成功するためにMITMの状況にいる必要があるなどの制約条件が多いものでした。しかし影響範囲は限定的であったにも関わらず、当初温度感の高い報道がなされているように感じました。「10年以上も放置」という事実もそれに拍車をかけていたと考えられます。
今回の問題は、ハンドシェイクメッセージの送受信において状態遷移のチェックさえ行っていれば、プロトコル上あり得ない箇所でインジェクションされたChangeCipherSpecメッセージをはじくことが出来ました。このチェックは特別なものではなく非常に簡易なものあってもこの攻撃は起こり得ません。HeartbleedBugのエンバグと同じタイミングである1.0.1系にて、新しい機能が追加される際に呼び覚ましてしまったバグであると認識されています。
OpenSSLは広く利用されている暗号ライブラリのひとつであり多くの目に触れられてきたものです。それにも関わらず今回の問題がこれまで発覚しなかったのは、オープンソースの潜在的な問題に依るものであることを再認識させられた方も多いと思います。また、利用者自身がよく理解していない新機能(例:Heartbeatプロトコル)をパッケージのデフォルトのまま利用してしまった側にも問題があるとも言えます。今後、OpenSSLに対する関心の高まりをうまく利用することで問題解決の方向に向けていくのか、しっかりとしたサポートの得られる商用製品に移行するのかについては考えが分かれるところですが、いずれにせよ見直しをするきっかけを与えてくれたと言えます。前者の一例として、OpenSSLを枯れた安全な技術として利用したいというニーズに対しては、絶妙なコンパイルフラグの調整を皆が協力して精査することで可能になるかもしれないことを挙げておきます。
先日、前述した2つの脆弱性をよく知る関係者からの指摘を受けて驚いたことがあります。Heartbleed BugのCVSS Base pointがかなり低いものであったということです。CVSS *2 は脆弱性評価指標の一方式で、当該脆弱性の「ヤバさ」を数値化することで、対策が必要かどうかを判断する一つの指標となっています。毎日公表される膨大な脆弱性情報から本当に対策が必要なものがどれであるかを、ある程度の精度でフィルタすることには役立つかもしれません。しかし直感的にも実際にも影響が大きいと認識されていたHeartbleed Bugは先週報告されたCCS Injectio攻撃よりもCVSS Base Scoreとしては低く評価されています。
ある脆弱性情報を受けて実際に対策が必要かどうかを判定する際にはCVSSなどの数値だけに頼らず、より詳細にその脆弱性を読み解く必要が出てきます。ソースコードの精査も含む実証実験だけでなく、場合によってはアカデミアから出てくる研究論文までさかのぼり、実際に起こりうる問題と影響範囲、その確度などを確定していく必要が出てきます。そのあとでこの脆弱性に対する対策方針とスケジュールを立案していきます。
これはかなり極端な事例と思われる方もいらっしゃるかもしれません。しかし「パッチがすでに公開されていてそれをあてるだけ」のマネージメント手法では、オープンソースの問題で指摘したように問題の中身・本質を十分理解しないままであることを認識しなければなりません。もちろん、報道の「アツさ」だけを判断材料にすることも問題です。特に暗号技術に起因または関連する脆弱性の場合には、この傾向が大きいように思います。アカデミアからの論文はチンプンカンプンだからと言って逃げることなく、正しく判断していく必要があります。そのための技術者連携方法として主要カンファレンスの読破会や暗号プロトコル評価技術コンソーシアム *3 という組織も立ち上がっていますので、ご興味のある方はコンタクトしてみて下さい。
次に最近よく目にする暗号技術に関連する脆弱性の傾向に触れておきます。具体的には以下の2つのカテゴリです。
(1)擬似乱数生成器の問題
(2)X.509証明書の検証時の不備
(1)は暗号技術で用いられるランダムデータに関する件です。擬似乱数生成モジュールは生成される値に偏りがないこと、予測できないという性質が必要です。もしそれが満たされていない場合には、公開鍵ペア生成時に秘密鍵が予測される*4、セッション鍵が予測される、署名生成時に秘密鍵が暴露してしまう *5 等の問題が生じてしまいます。これらの問題は例えば昨年11月に開催された ACMCCS2013 *6 で randomness セッションが組まれるなどアカデミアでも流行りの研究だということが分かります。
(2)はSSL/TLSなどで利用されている公開鍵証明書に関する件です。先月開催されたIEEE S&P2014 *7ではSSL/TLSセッションが組まれており、やはり同じように盛んに研究が進められている分野であると言えます。S&P2014 では併設ワークショップも含めSSL/TLSに関連する5件の発表が行われており、不正な証明書やSSL/TLSサーバの設定不備に関する調査報告3件、2009年に発覚した Renegotiation 機能の問題と同類のプロトコル脆弱性の報告1件、そして(2)に挙げたようにX.509証明書の検証時の不備に関する報告1件がありました。最後の1件は昨年に引き続き同じチームがBest Practical PaperAwardを受賞しているなど非常に現実的な問題を取り扱っています。フランケン証明書*8はその名の通り、流通している様々な証明書のパーツを組み合わせて出来上がる証明書のことで、これを大量に作成し検証モジュールに対してFuzzingすることでモジュールの問題点を洗い出しており、いくつかの商用製品において脆弱性が発見されています。
(1)(2)ともに今後も同様の問題が露呈することが予想されます。特にOpenSSL以外のマイナーなモジュールへの展開が見込まれており、どのような組み合わせでシステム・サービスを構築しても、潜在的には同じようなバグが埋め込まれている可能性があることを知った上で利用しないといけません。さらに暗号アルゴリズムそのものも経年劣化だけでなく、突発的な攻撃手法の公開により急に安全でなくなるかもしれないことを理解した上で暗号技術を利用していく必要があります。
最後に、暗号技術に関連する脆弱性の整理方法として、暗号危殆化・設計・実装・運用の問題という4つのカテゴリに分類する方法(2012年12月までの事例も併記)も紹介しておきます*9。また、暗号研究者と暗号利用者のギャップを埋めていくWorkshop on Real-World Cryptography などの試みも見受けられるようになりました。JNSAや他の組織からも日本発で同じようなアクティビティが出来ればと常に考えています。ご興味のある方はお気軽にお声がけ頂ければと思います。
*1 CVE-2014-0224 http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0224