広く Javaアプリケーションサーバに影響する Javaライブラリの脆弱性の存在が報道、公表されています。本件は多くの問題を内包し、複雑です。本記事では、その影響範囲と問題点を正しく理解するために、情報の整理を行いたいと思います。
■この脆弱性の概要
この脆弱性は、Java のデシリアル化処理を利用して任意のコードを実行可能、というものです。すでに 2015年1月に行われた AppSecCali 2015の「Marshalling Pickles」と題する発表の中で、セキュリティ研究者の Gabriel Lawrence氏と Christopher Frohoff氏により、PoC（概念実証コード、攻撃コード）が公開されています。この PoC の対象のクラスは「Apache Commons Collections」「Spring」「Groovy」です。
■この脆弱性の影響範囲と深刻度
そして 2015年11月、FoxGlove Security のブログポストにより、先に発表されていた PoC を利用して主要Javaアプリケーションサーバなどのミドルウェアを攻撃可能であるという検証結果が公開されました。現時点では本件そのものを指す CVE番号は採番されていません。Weblogic（CVE-2015-4852）や Groovy（CVE-2015-3253）のように、ミドルウェアごとに個別の CVE番号が採番されています。
- 公開されている PoC の内容
PoC が公開されているのは、脆弱なバージョンの「Apache Commons Collections」「Spring」「Groovy」を利用する環境において、シリアル化されたオブジェクトのデシリアル化処理を実行する際に任意のOSコマンドを実行可能という攻撃シナリオです。このPoCを用いることで、攻撃用のペイロードを簡単に作成可能です。 - PoC で実証された脆弱性の内容
この PoC は「Property-Oriented Programming」と呼ばれる、読み込み済みのライブラリのコードを再利用してプログラミングを行う手法で作成されたものです。この手法で作成したコードはここでは「ガジェットチェーン」と呼ばれます。今回 PoC が公開された Javaライブラリには、OS上でのコマンド実行を含む任意のコードが実行可能なガジェットチェーンを作成できる脆弱性があったのです。
このようなデシリアル化処理に関連するガジェットチェーンが作成可能な脆弱性は、かねてより他の言語の他のライブラリにも発見され、研究者から報告されています。 - PoC の影響を受ける環境
脆弱なバージョンの「Apache Commons Collections」「Spring」「Groovy」の jarファイルが classpath に読み込まれており、RMI や SOAP、その他独自の方法などで外部からシリアル化された Javaオブジェクトを入力として受け付ける環境が影響を受けます。例としてすでに言及されているミドルウェアは Oracle Weblogic, IBM WebSphere, RedHat JBoss, Jenkins, OpenNMS です。独自に開発したシステムでも、JVM が対象の jarファイルを読み込んでおり、外部からシリアル化された Javaオブジェクトを入力として受け付ける場合は影響を受けることに注意してください。Weblogic や WebSphere に対して可能だと言われているのは、アプリケーションサーバを起動または停止するために通常、組織内で使用する管理ポートへの攻撃です。これらのアプリケーションサーバ上で稼働するすべての Webアプリケーションに影響があるわけではありません。受け付ける入力にシリアル化された Javaオブジェクトを含まない、つまり入力がユーザーのマウス操作やキー入力、文字データや画像のみであるような Webアプリケーションであれば影響を受けません。
また、この PoC自体には認証をバイパスする機能はないため、認証によって信頼されない外部からの入力を拒否していれば影響を受けません。環境への入力に認証が必要な場合、攻撃者は別の方法で認証を突破する必要があります。
- この脆弱性の深刻度
この脆弱性を利用することで、最悪のシナリオでは、Webアプリを提供するサーバ上で OSコマンドの実行を含む任意のコードを遠隔から実行することが可能です。つまり望まない OSコマンドの実行によるサービス停止やファイル削除などの攻撃が可能です。ただし上でも述べた通り、認証によって信頼されない外部からの入力を拒否していれば影響を受けません。
■管理者は何をすべきか
その影響範囲の広さと深刻さに反し、この脆弱性を利用した攻撃可能性はあまり高くないものと見積もることができます。攻撃成立には認証の突破が必要であるため、また昨今のサイバー犯罪者の興味の大半はもっと直接的な金銭や情報の窃取に偏っているためです。
すぐにパッチ適用や設定変更などの対処が必要となるのは以下の条件すべて満たす場合です。攻撃可能性を下げるため、条件のどれか一つを外す対処を行いましょう。
- PoC の対象のクラスを読み込んでいる
- 外部入力としてシリアル化された Javaオブジェクトを受け入れている
- 外部入力に認証が掛かっていない
一般的に運用されているシステムの多くは、この条件をすべて満たすことはないものと考えられますので、Webアプリの管理者は冷静に対処できると言えるでしょう。恒久的な対処方法についてはクラスや各ミドルウェアの提供元から修正パッチや回避策の案内が出始めています。
■根本的な問題解決
この PoC が公開された「Marshalling Pickles」の発表には「オブジェクトのデシリアル化処理はいかにしてあなたの一日を台無しにするか」という副題がついており、Java に限らずシリアル化されたオブジェクトを受け取り、デシリアル化処理を行う場合の危険性について広く述べられています。
なかでも強く「脆弱性は非安全なデシリアル化処理にあるのであり、PoC があることが脆弱なのではない」と述べられています。デシリアル化処理には脆弱性ができやすいため、これを安全に行うための方法として、デシリアル化するクラスをホワイトリストでフィルターする（resolveClass のオーバーライド）、単なる暗号化ではない適切な認証方法を利用することなどが紹介されています。
Java に限らず他の言語環境でも、今後デシリアル化処理に関連する「ガジェットチェーン」が作成可能な脆弱性が発見される可能性は十分にあり、今回の件はモグラたたきゲームのスタートにも思えます。しかしながら、危険性があるからといってすべてのシリアル化・デシリアル化処理を完全に避けようと考えるのは、この問題の本質とは異なります。我々はこの問題から、安全にこれらを使用するためには、開発の際に上記のような基本的な対策を地道にとっていく必要があることを学ぶべきなのです。