「Java 7 Update 11でも脆弱性は残っているから引き続きJava無効化を」という話について

Java SE 7 Update 11が対策した脆弱性は、「CVE-2013-0422」と「CVE-2012-3174」の２つと書かれています（http://www.oracle.com/technetwork/topics/security/alert-cve-2013-0422-1896849.html 英語）。

このうち、ここ数日話題になっていた脆弱が「CVE-2013-0422」です。

これに対し、「これらの脆弱性に対してリリースされたJava 7 Update 11では不十分だ」という記事が出てきました。

ただ、複数読んでみると、どうも微妙にニュアンスが違いました。これについて、自分がどう混乱したか、書いてみます。

記事の例：cnetに載っていた記事

「ウェブブラウザ上でJavaを絶対に実行しなければならないという場合を除き、7u11へのアップデート後も以下の手順で同プラグインを無効化しておいてほしい。これによって、将来的に発見されるかもしれないJavaのその他の脆弱性を回避するうえで役立てることができるだろう」 （引用元）

これを読んで、私は「なんだ、将来の新しい脆弱性に備えろ、ってことか。また似たようなことが起こるかもしれないから普段から気を付けろ」ってことね、にしてもやたら厳しめだな」と思ってしまいました。

さらに続きにある、「Immunityの話」の部分を読んでみます。

DHSは、Oracleのアップデートがたった1つの脆弱性にしか対応しておらず、その他の脆弱性はいまだに残っているという、セキュリティ企業Immunityによるレポートを引用している。 （引用元）

すると今度は、「あれ？あぁ、脆弱性の修正残しがあるのか、それは大変だ」と感じました。

実は、「Oracleは修正でセキュリティレベル『高』をデフォルトにしたので、承認ボタンを押さないとJava appletが実行できない」という話もあるので、「ああ、セキュリティレベルだけで対処したのか」とそのときは思いました。

しかし、さらに続きを読んでみます。

「Javaのコードについて十分な知識を有している攻撃者は、今回対応された脆弱性に代わる他のゼロディ脆弱性を利用することで、簡単にユーザーを危険に陥れることができる」 （引用元）

すると今度は「あれ？脆弱性が残ってるってさっき言ったのに、どうして脆弱性をまた発見しないと攻撃できないの？」となります。

実はこれは翻訳記事で、元の英語を見ると、印象が違います。今の日本語の翻訳記事部分に対応するであろう部分がこちらです。

"The patch did stop the exploit, fixing one of its components," Immunity said in a blog post today. "But an attacker with enough knowledge of the Java code base and the help of another zero day bug to replace the one fixed can easily continue compromising users." （引用元）

このように元の英語では、「The patch ... one of its components,」というところから引用しており、「たしかに攻撃コード（exploit）は無効化できたこと」と「そのexploitの原因の一部分が修正された（修正された部分と修正されなかった部分とに関連がある、もしかしてCVE-2012-3174とCVE-2013-0422には関係があった？）ということ」が読み取れます。そして、ここから「防がれたほうのバグを、他のバグを見つけて置き換えてしまえば、引き続き攻撃可能である」という内容につながっており、前提知識が加わった結果「え、それが見つかったら危険な状態にすぐ陥るってこと？」という印象になります。さきほどの「どうして脆弱性をまた発見しないと攻撃できないの？」という印象とはだいぶ違います。

いろいろややこしくて、どうも気になります。すっきりしません。

@ITの記事

一方、@ITでは、同様の内容を次のように書いています。

Immunityは、OracleがJava 7 Update 11で修正したとする「CVE-2012-3174」と「CVE-2013-0422」の脆弱性のうち、実際に修正されているのはCVE-2012-3174のみで、アップデートを適用しても、JMX MBeanに存在するCVE-2013-0422の問題は残ったままのようだとする分析結果を公開した。 （引用元）

私にはこの文章が「二つの脆弱性は独立していて、片方の攻撃方法がそのまま生き残っている」と読めました。「別の脆弱性が見つかったら」というニュアンスが省かれていることに加え、まるごと危険性が残っているという印象があります。二つの脆弱性の関連性は見えてきません。

※追記（2013-01-16）：本日この記事は、「引き続きJavaの無効化を：Oracle、Javaのアップデート公開も、修正された脆弱性は1つだけ？」というタイトルから「未知の脆弱性に備えて不要なJavaは引き続き無効化を：Oracle、Javaのアップデート公開」に変更され、本文にも修正が加えられました。

というわけでなんだかやたらよくわからないので、CERTや、cnetの記事、@ITの記事、すべてが情報源にしているImmunityのブログ記事を読んでみます。

Immunityのブログでは、まず大前提として、「２つのバグが『セット』でリモートで任意のコードを実行できる」と言っています。

This is the case of the recent MBeanInstantiator exploit, which combines two bugs in order to remotely execute code. （引用元）

「あ、なるほど、そっち？」という印象です。

これを把握した上で、次の文章を読むと、Oracleは「CVE-2012-3174」に対応するバグしか修正しなかったけれど、それが無いと「CVE-2013-0422」は成立しないから、たしかに「CVE-2013-0422」と「CVE-2013-0422」をターゲットにした攻撃コードは使えなくなったということがわかります。

The patch did stop the exploit, fixing one of its components. But an attacker with enough knowledge of the Java code base and the help of another zero day bug to replace the one fixed can easily continue compromising users. （引用元）

なので、今までの印象では、「なんだ、Oracle片方しか直さないなんてひどい」だったのですが、「なんだ、片方直すだけで、とりあえず一時しのぎにはなるのか。片方だけでもリリースした価値はあるね」という印象になりました。

結局このブログが指摘しているのは、「CVE-2012-3174」の原因になった「java.lang.invoke.MethodHandleNatives.isCallerSensitive」にあるバグは修正されていたけれど、「CVE-2013-0422」の原因になった「com.sun.jmx.mbeanserver package」には何も変更がないから、これとまた別の脆弱性が組み合わせられるかもしれない！気を付けて！という話のようなのです。

the patch (which is Java 7 update 11) doesn't show any difference at all in the classes inside com.sun.jmx.mbeanserver package. （引用元）

周囲まで読んでみると、「残っているのはCVE-2013-0422に対応するほうのバグであり、これはCVE-2012-3174と組み合わせることで、今回話題になっていたJava 7u10以下に対する攻撃手段（MBeanInstantiator exploit）はそのまま利用できず、CVE-2012-3174の代わりになる脆弱性を誰かが見つける必要があって、でも腕利きの人なら見つけられそうで、実際それが見つかったら再び攻撃されるよ」という内容が書かれています。

ただし実は、ブログのコメント欄に「CVE-2012-3174 is *not* "the Recursive Reflection vulnerability." It is a distinct vulnerability from anything used in the exploits/PoCs for CVE-2013-0422.」とも書かれていて、特にコメント返しも行われていないので、正直「えええええ、どっちだよ」って感じです（この２つのバグが、CVE-2012-3174とCVE-2013-0422に１つずつ含まれているか、CVE-2013-0422に２つとも含まれているか、のどちらかだとは思います。しかしどちらにしても、とりあえず片方のバグを防いだだけで、状況が多少なりとも改善された（攻撃コードがそのままでは使えなくなった）というのは確かだと思います）。

このような記事の裏側になった細かい話はあるにせよ、cnetや@ITのどちらの記事も、最終的にCERTの文書（Vulnerability Note VU#625617 - Java 7 fails to restrict access to privileged code）にある

Unless it is absolutely necessary to run Java in web browsers, disable it as described below, even after updating to 7u11. This will help mitigate other Java vulnerabilities that may be discovered in the future. （引用元）

に相当する、「引き続きブラウザ上のJavaプラグインは無効化しましょう」という内容を書いています。

こうやってみると、同じ情報源でも、それをまとめ方や引用箇所、補足説明の有無などによって、まったく印象が変わってしまうのだなぁ、というのがよくわかりました。

正直、細かい部分（CVE-2012-3174とCVE-2013-0422との関係性）は、今のところ私にはよくわからないので、Immunityの記事頼みとなってしまったのですが、それ自体よりも、情報源を確認すると見えてくるものが思った以上に多いというところが印象に残りました。なかなか毎回確認するわけには生きませんが、せめて今回のように「違和感」を覚えたら、チェックしてみると「すっきり」できるかもしれません。

詳しい方、よかったら、CVE-2012-3174とCVE-2013-0422の関係、教えてください;

自分で調べました。

「CVE -CVE-2013-0422 (under review)」に次のような内容が書いてありました。

• CVE-2013-0422は、「JmxMBeanServerの脆弱性」と「recursive Reflection APIの脆弱性」の両方を指している
• CVE-2012-3174はたしかに「recursive Reflection API」の問題だが、CVE-2013-0422の「recursive Reflection APIの脆弱性」とはまた別のものであって、そもそも詳細は2013年1月14日時点で未だ公表していない
• しかし、組織（some parties）によっては、CVE-2013-0422のrecursive Reflection APIの問題をCVE-2012-3174のrecursive Reflection APIの問題としてしまっている

つまりImmunityは、まさにこの二つの脆弱性を混同してしまっていたようです。しかし、「２つの脆弱性（CVE）のうち片方しか直されていない」は間違っていますが、「２つの脆弱性（バグ）のうち片方しか直されていない」という意味では間違っていなさそうなので、各脆弱性（バグ）がどのCVE-IDに属すかという認識に間違いがあるだけであって、CVE-2013-0422の原因となる脆弱性についての認識を否定するものではないことに注意が必要です。

ただそうなると、Oracleも、同様の認識間違いをしている可能性も感じたのですが、「CVE -CVE-2012-3174 (under review)」によればまぁそんなことはなく、脆弱性（どう脆弱なのか）は非公開なものの、たしかにちゃんとJava 7 Update 11で修正されたようです。

したがって、「CVE-2012-3174とCVE-2013-0422のうち、片方しか直さなかった」という表現をしたとしたら、それは間違いである、といえそうです。

どっちも同じコンポーネントに起因するとか、なんたるややこしさ。