Apacheの対処と見解
Apacheは、本問題に対処したライブラリ（v 3.2.2およびv 4.1）をリリースした。
v 3.2.2では初期状態でInvokerTransformerなど問題があるいくつかのクラスのシリアライズ・デシリアライズを無効化しており、攻撃を試みた場合は、InvokerTransformerのデシリアライズに失敗し、例外が発生する。結果として任意のコードは実行されない。
java.lang.UnsupportedOperationException: Serialization support for org.apache.commons.collections.functors.InvokerTransformer is disabled for security reasons. To enable it set system property 'org.apache.commons.collections.enableUnsafeSerialization' to 'true', but you must ensure that your application does not de-serialize objects from untrusted sources.
ただし、上記メッセージのとおり、JVMオプション（org.apache.commons.collections.enableUnsafeSerialization=true）により有効化が可能なため、メッセージを読んだ保守担当者などが事象を理解しないままJVMオプションを有効化してしまわないように注意が必要である。
v 4.1では、問題があるいくつかのクラスのシリアライズ・デシリアライズが完全に無効化されている（Serializableを実装しない）。
Apacheの公式見解では「攻撃に使えるクラスは今回指摘されたもの以外にも存在するかもしれないため、Commons Collectionsライブラリを対策版に置き換えるだけでは本脆弱性の完全な対策とはならないだろう」と述べている。
また、現時点でApacheには脆弱性識別番号（CVE）が割り当てられていない。MITRE社は、問題はライブラリ側で想定する動作と言語が固有にもつ動作の不整合や利用者側のインセキュアな実装などにも起因しており、CVEを割り当てる予定はないとコメントしている。
同様の問題がすでにSpringやGroovyでも見つかっている。また、別のセキュリティ研究者によって、Commons Collectionsに依存する代表的なライブラリの一覧が公開されている。クラスパス上に当該ライブラリが存在し、外部からシリアライズされたデータを受け取るアプリケーションを開発している場合、デシリアライズ時の検証を行っているか、いまいちど確認してほしい。
任意のコードを実行するGadget Chainの生成が可能で、かつシリアライズ可能なクラスが他にも存在する場合、その仕組みを悪用した攻撃手法が公開される可能性がある。そのため、冒頭で述べたように、デシリアライズ処理をセキュアに実装することが本質的な対処となる。
次回記事では、より一般的なデシリアライズの問題とその対策を解説していこうと思う。
Commons Collectionsの問題に関する主なイベント
まとめとして、Commons Collectionsの問題に関する主なイベントを、参考までに時系列で整理しておく。
- 2015/11/28: Commons Collections 4.1リリース
- 2015/11/17: MITRE CVE Teamがoss-securityにコメント投稿
- 2015/11/15: 警察庁がWebLogicサーバの脆弱性探索目的と考えられるアクセスについて注意喚起発行
- 2015/11/15: Commons Collections 3.2.2リリース
- 2015/11/10: ASF Blogにstatement掲載
- 2015/11/07: issues.apache.orgにCOLLECTINOS-580作成
- 2015/11/06: foxglovesecurityのブログで、APサーバの攻撃手法公開
- 2015/01/28: AppSecCali2015にて"Marshalling Pickles"講演（Christopher Frohoff氏）
（次回へ続く）
