Apache Commons Collections ライブラリの非直列化処理に脆弱性

no extension

1週間以上前の話で,なんだか今更なんだけど,全く仕事に絡んでないこともないので,覚え書きの形で残しておく。 なお,今回のケースは Java 以外にも広がるかもしれないので,類似情報に注意しておいた方がいいだろう。

脆弱性の内容

発端はこれ。

2015年1月に開催された AppSec California 2015 において、Gabriel Lawrence 氏と Chris Frohoff 氏は、信頼できないデータをデシリアライズしてしまう脆弱性について講演し、任意のコードを実行可能であることを示しました。
via Apache Commons Collections ライブラリのデシリアライズ処理に脆弱性
AppSecCali 2015 - Marshalling Pickles

この際に PoC(Proof-of-Concept; 概念実証コード)も公開されている。

更に両氏は今月になって,この PoC を使って Apache Commons Collections ライブラリを使用するいくつかのミドルウェアおよび Groovy, Spring が攻略可能であることを示した。

影響を受ける製品

  • Apache Commons Collections ライブラリのバージョン 3.2.1 および 4.0
  • Groovy や Spring の一部バージョン
  • 上記ライブラリまたはフレームワークが classpath に読み込まれている状態で,シリアル化された Java オブジェクトを外部から受け付けている環境
    • WebLogic, WebSphere, JBoss, Jenkins, OpenNMS 等のミドルウェア製品
Weblogic や WebSphere に対して可能だと言われているのは、アプリケーションサーバを起動または停止するために通常、組織内で使用する管理ポートへの攻撃です。これらのアプリケーションサーバ上で稼働するすべての Webアプリケーションに影響があるわけではありません。受け付ける入力にシリアル化された Javaオブジェクトを含まない、つまり入力がユーザーのマウス操作やキー入力、文字データや画像のみであるような Webアプリケーションであれば影響を受けません。
via 主要Javaアプリケーションサーバに影響するJavaライブラリの脆弱性を正しく理解する

さらに

  • Java 以外にも Python, Ruby などで書かれたアプリケーションやライブラリにも同様の脆弱性がある可能性が指摘されている

影響度(CVSS)

CVSSv2 基本評価値 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P)

基本評価基準 評価値
攻撃元区分(AV) ネットワーク(N)
攻撃条件の複雑さ(AC) 低 (L)
攻撃前の認証要否(Au) 不要(N)1
情報漏えいの可能性(機密性への影響, C) 部分的(P)
情報改ざんの可能性(完全性への影響, I) 部分的(P)
業務停止の可能性(可用性への影響, A) 部分的(P)

CVSS については解説ページを参照のこと。

対策・回避策

回避策としては以下のとおり。

  • 外部入力に認証をかける(今回の PoC には認証をバイパスする機能はない)
  • 外部入力にシリアル化された Java オブジェクトを受け付けない,または受け付けるオブジェクトを限定する
  • PoC 対象のクラス(ACC ライブラリであれば InvokerTransformer クラス)を使用しない。

さらに根本的な対策としてアプリケーションの設計の見直しが推奨されている。

However, to be clear: this is not the only known and especially not unknown useable gadget. So replacing your installations with a hardened version of Apache Commons Collections will not make your application resist this vulnerability.
via Apache Commons statement to widespread Java object de-serialisation vulnerability
Apache Commons Collections ライブラリの対策版リリースの準備が進められています。しかし、現状提案されているパッチはシリアライズ機能をデフォルトで無効にするだけのものです。当該ライブラリのシリアライズ機能が必要な場合には、この機能を有効にするコードを追加するとともに、安全にデシリアライズするようアプリケーションの設計を見直す必要があります。
via Apache Commons Collections ライブラリのデシリアライズ処理に脆弱性
この PoC が公開された「Marshalling Pickles」の発表には「オブジェクトのデシリアル化処理はいかにしてあなたの一日を台無しにするか」という副題がついており、Java に限らずシリアル化されたオブジェクトを受け取り、デシリアル化処理を行う場合の危険性について広く述べられています。
なかでも強く「脆弱性は非安全なデシリアル化処理にあるのであり、PoC があることが脆弱なのではない」と述べられています。デシリアル化処理には脆弱性ができやすいため、これを安全に行うための方法として、デシリアル化するクラスをホワイトリストでフィルターする(resolveClass のオーバーライド)、単なる暗号化ではない適切な認証方法を利用することなどが紹介されています。
via 主要Javaアプリケーションサーバに影響するJavaライブラリの脆弱性を正しく理解する

ベンダの対応

  • WebLogic : 最新版は対策済み(回避策
  • WebSphere : 最新版は対策済み
  • JBoss : 最新版は対策済み(一部パッチ準備中),危険なクラスを削除
  • Jenkins : 最新版は対策済み
  • OpenNMS : Port 1099 の遮断で回避
  • Groovy : 最新版は対策済み
  • Spring : 最新版は対策済み

参考


  1. PoC による攻撃に限るなら認証をバイパスできないため,外部入力に認証をかけている場合は評価値は7未満になる。今回のようなケースは CVSSv2 では評価が難しいかも。 CVSSv3 で評価し直した方がいいかな。 [return]