「Javaライブラリに脆弱性、主要ミドルウェア全てに影響」ってマジですか！

2015/11/17追記
JVN や CERT、MITRE に情報が出てますので、こちらも併せてお読みください。
JVNVU#94276522: Apache Commons Collections ライブラリのデシリアライズ処理に脆弱性
Vulnerability Note VU#576313 - Apache Commons Collections Java library insecurely deserializes data
CWE - CWE-502: Deserialization of Untrusted Data (2.8)

Apache commons-collection が今アツい。。。なのに冷や汗出まくりですわ。
情報を把握しきれていないのが一番の問題なわけですが。

www.itmedia.co.jp
なんかやばそう。。。

こちらが発見者の記事らしいんだけど。。。foxglovesecurity.com

What this means is that any application or application framework that uses it (there are many), and unserializes untrusted data (again many) now has an open CVSS 10.0 vulnerability. This means:

CVSS 10.0 とか言ってますよ。これって即死じゃないですか。。。

シリアライズされたオブジェクトに Runtime.exec() が発動するような毒を仕込んでおき、それを流しこむだけでOKという話っぽい？ですよね。これヤバすぎ。

もっとも、この場合の問題は「信頼できない経路で入手した、シリアライズされたデータを無条件にデシリアライズする」点にあるでしょうから、そういう穴が無ければ多分大丈夫？

それとも、たとえば tomcat の lib に commons-collections.jar が配備されていると、tomcat 自体がアカンやつになるんですかねえ。

特定の servlet とかに commons-collections.jar が含まれている場合は、たぶんその servlet だけがアカンやつなのでしょうけど。

で、対処方法を調べてみると。。。

For those faint of heart, you can be a little more surgical about it. If we examine the two exploits provided by the “ysoserial” tool, we can see that they both rely on the “InvokerTransformer” class. If we remove this class file everywhere it exists, any attempted exploits should fail. Feel free to open up your jar files with your expired copy of Winzip and delete the file at “org/apache/commons/collections/functors/InvokerTransformer.class”.

commons-collections*.jar から org/apache/commons/collections/functors/InvokerTransformer.class を消せとおっしゃってますな。

消して問題がないアプリならありですよね。しかし問題が出る場合はこの手は取れない。。。

本件の暫定的なパッチは COLLECTIONS-580 としてリリースされておるようです。
[COLLECTIONS-580] Arbitrary remote code execution with InvokerTransformer - ASF JIRA

内容を見ると以下の修正が行われている様子。

• private readObject にて、最初に assertSerializable() の try を行うようになった。
• private writeObject() が追加されていて、こちらも最初に assertSerializable() を行う。これはデフォルトの writeObject によるデシリアライズを避けるためのオーバーライド実装であるとコメントが書かれてますね。
• assertSerialize() は元々は readObject の内部実装であったが、writeObject の追加実装により、これを private として readObject の外に出している。
• deserializeProperty が true の場合を除き、UnsupportedOperationException を投げるようになった。

これなら大丈夫ですよねえ。この修正を入れて Exception が出るようなアプリケーションは deserializeProperty を true にせねばならないのでしょうけど、それはそもそも実装が腐っていると考えてもよいのかもしれない。

結局、InvokerTransformer.class を消すにしろ、修正するにしろ、Exception を出して処理が止まる点は本質的には同じであり、そのときの Exception が ClassNotFound かどうかの違いくらいしか無さげかも。

しかしこれで Apache commons-collections は一応なんとかなるとして、java の標準ライブラリは大丈夫なのですかねえ。今回の件は、古いPHPの実装で GET / POST のどちらで投げられたパラメータでも内部変数に自動的に代入してしまうような余計なお世話的な事象だと思いますし、標準ライブラリはそういう有難迷惑なことをしないと思いたいわけですが。