2015-11-12

参考訳:拡散したJavaシリアル化の脆弱性についてApache Commons声明

原文:https://blogs.apache.org/foundation/entry/apache_commons_statement_to_widespread

原題Apache Commons statement to widespread Java object de-serialisation vulnerability

翻訳日:2015年11月12日(午後にタイトル日本語しました)

----

2015年11月1日 火曜日

Apache CommonsJavaオブジェクトのデシリアライゼーション脆弱性に関するステートメント

著者:Bernd Eckenfels(コミッター), Gary Gregory(Apache Commons副責任者)

AppSecCali2015 でGabriel Lawrence (@gebl) と Chris Frohoff (@frohoff) によって発表された "Marshalling Pickles - how deserializing objects will ruin your day" は、信頼されないソースからシリアル化されたオブジェクトを受け取るときセキュリティ問題をいくつか明らかにしました。主な発見は、Java オブジェクトシリアライゼーション(訳注:seriarization/シリアル化/直列化=ネットワークで送受信できるようにメモリ上のオブジェクトデータバイト列で吐き出すこと。シリアル化されたJava オブジェクトRMIなどのリモート通信プロトコル使用される。)を使用する際に任意Java関数の実行や操作されたバイトコードの挿入さえもを行う方法説明です。

Frohoff氏のツールである ysoserial を使って、Foxglove Security社のStephen Breen (@breenmachine) 氏はWebSphereJBossJenkinsWebLogic、OpenNMSといった様々な製品調査し、(http://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenkins-opennms-and-your-application-have-in-common-this-vulnerability/) に各々の様々な攻撃シナリオ記述しています

両者の調査活動は、開発者Javaオブジェクトシリアライゼーションに信頼を置きすぎていることを示しています認証前のシリアル化されていないオブジェクトにも。

Javaにおけるオブジェクトのデシリアライゼーション(訳注:de-serialization/非直列化=ソフトウェアで扱うことができるように、送受信されたデータを元に戻すこと)が行われるとき、大抵は想定された型にキャストされ、それによって、Javaの厳しい型のシステムが、得られた有効オブジェクトツリーだけを保証しています

不幸にも、型のチェックが起こるまでの間に既にプラットホームコードが生成されて、重要ロジックは実行されてしまっています。そのため、最終的な型がチェックされる前に、開発者コントロールを離れた多くのコードが様々なオブジェクトの readObject() メソッドを通じて実行されてしまます脆弱性のあるアプリケーションクラスパスから得られるクラスの readObject() メソッドを組み合わせることで、攻撃者は(ローカルOSコマンドを実行するRuntime.exec()の呼び出しを含めて)機能を実行することができます

これに対する最も良い防御は、信頼されていないピア通信相手)とは複雑なシリアルプロトコルを使うことを避けることです。ホワイトリストアプローチ http://www.ibm.com/developerworks/library/se-lookahead/実装するように resolveClass をオーバーライドするカスタム版の ObjectInputStream を使うと、影響を制限することができますしかしながら、これは常にできることではなく、フレームワークアプリケーションサーバがエンドポイント提供しているような時にはできません。簡単な修正方法がなく、アプリケーションクライアントサーバプロトコルアーキテクチャを再検討する必要があるため、これはかなり悪いニュースです。

これらのかなり不幸な状況において、エクスプロイトのサンプルが見つかっています。Frohoff氏は、 Groovy ランタイムSpringフレームワークApache Commons コレクションからクラスを組み合わせるサンプルのペイロードに gadget chains (ガジェット・チェーン)を見つけています(訳注:provided)。これはこの脆弱性エクスプロイトのためにより多くのクラスを組み合わせられることは完全に確実なことで、しかし、これらは今日攻撃者が簡単に得られるチェーンです。

(Twitter画像)https://blogs.apache.org/foundation/mediaresource/ce15e57e-94a4-4d7b-914c-8eb8f026659c

この脆弱性のために利用される(訳注:blamed)ことができない確かな機能実装するクラスができ、安全性が信用できないコンテキストにおけるシリアル化を利用されないようにするような既知のケースの修正ができたとしても、少なくとも分かったケースだけでも継続的修正していくことが要求されますモグラ叩きゲームを始めるだけであるかも知れませんが。実際にはこれは、オリジナルチームが Apache Commons チームに警告が必要だと考えていない理由で、それゆえに比較的、活動開始が遅れました。

Apache Commons チームは InvokerTransformer クラスのでデシリアライゼーションを無効化することによって commons-collection の 3.2 と 4.0 のブランチにおける問題対処するために、チケット COLLECTION-580(http://svn.apache.org/viewvc/commons/proper/collections/branches/COLLECTIONS_3_2_X/src/java/org/apache/commons/collections/functors/InvokerTransformer.java?r1=1713136&r2=1713307&pathrev=1713307&diff_format=h) を使っています議論されているやるべきことのアイテムは、変化させる仕組み毎(per-transformer basis)に、プログラマティックに有効にするような機能提供するかどうかです。

これには前例がありますOracle と OpenJDK JRE の一部であったり、バイトコードを挿入して実行することを許したりする com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl クラスで、セキュリティマネージャー定義されているとデシリアライゼーションを拒否します。

これはシステムプロパティ jdk.xml.enableTemplatesImplDeserialization=true とすることで無効にできますApache Commons Collection は、本来よりもこの実行モデルは一般化していないため、セキュリティマネージャー存在独立したこの機能無効化することを計画しています

しかしながら、明確化のために述べておくと、この便利な"ガジェット"は、唯一知られている方法でもなければ、特に未知のものでもありません。そのため、インストールされたものを強化されたバージョンApache Commons Collection に置き換えることが、アプリケーションをこの脆弱性に対抗できるようにするわけではありません。

このブログポストレビューのために Gabriel Lawrence に感謝したいと思います

Apache Commons Collection は、Java コレクションフレームワークに加えて追加のコレクションクラス提供する Java ライブラリです。InvokerTransformerコレクションにあるオブジェクトを(特にリフレクション呼び出しを通じてメソッドを呼び出すことで)変換するために使うことができる Transformer ファンクションインターフェース実装の一つです。

一般のSallyによる2015年11月10日午前10字15分にポスト | コメント[1]

コメント

OracleWeblogicセキュリティアラートを発行しています

http://www.oracle.com/technetwork/topics/security/alert-cve-2015-4852-2763333.html?evite=WWSU12091612MPP001

提供されている回避策は、T3プロトコルへのアクセス(とリバースプロキシーにおけるT3メソッドフィルタリング)です。

記事への反応(ブックマークコメント)

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん