信頼できないデータのデシリアライズ：pickle と Java serialization

概要

pickle ストリームは、スタックマシン向けの小さなプログラムです。そのオペコードは任意のモジュールをインポートし、任意の呼び出し可能オブジェクトを引数付きで呼び出せます。pickle.loads はこの仕組みでオブジェクトを再構築します。引用した Python の文書は、このモジュールが安全ではなく、悪意のある pickle データが復元時に任意のコードを実行できるため、信頼できない出所のデータを決して unpickle してはならないと警告しています。「Restricting Globals」節では、それでも利用が残る場合の緩和策を示しています。Unpickler を継承し、find_class をオーバーライドして、明示的なモジュール名と名前の組だけを許可します。Java の ObjectInputStream も同様です。ストリームがクラスを指定し、実行環境がインスタンスを生成して、その readObject、readResolve、readExternal のロジックを実行します。通常のライブラリークラスの連鎖（「gadget chains」）が、これをコマンド実行へと変えます。引用した Oracle の文書は、その対策としてシリアライズのフィルタリングを説明しています。jdk.serialFilter パターンを単一アプリケーションのシステムプロパティー、または JVM 全体のセキュリティープロパティーに設定すると、クラス名を許可・拒否し、配列サイズ、グラフの深さ、参照数、ストリームのバイト数を制限できます。独自のフィルターは ObjectInputFilter API を実装します。

重要性

これらの形式はキャッシュ、ジョブキュー、セッションストア、RPC に便利なため、やがて信頼境界を越えたデータを読むようになります。Cookie、別のテナントが書き込めるキュー、アップロードされたファイルなどです。攻撃者は、あなたのコードのバグを必要としません。デシリアライザーと、クラスパスまたはインポートパスにあるクラスだけで足ります。

適用方法

• 境界を越えるものには、スキーマ検証を伴うデータ専用形式（JSON、Protocol Buffers、MessagePack）を優先します。pickle と Java serialization は、同じ信頼できるプロセスが生成し消費するデータに限定します。
• pickle を受け入れる必要がある場合は、pickle の文書が勧めるように、サーバー側の鍵を使った HMAC で署名し、読み込む前に検証します。その場合でもグローバルオブジェクトを制限します。
• Java では、許可リストとリソース制限（maxdepth、maxarray、maxrefs、maxbytes）を指定した jdk.serialFilter を設定するか、引用した OWASP のチートシートのように resolveClass をオーバーライドします。また、Serializable である必要があるドメインクラスには、例外を投げる readObject を用意します。
• コードレビューで pickle.load、ObjectInputStream、readObject、XMLDecoder、XStream.fromXML を grep で検索します。チートシートには Java の入口が列挙されています。
• 通信上の Java ストリームは、バイト列 AC ED 00 05（Base64 では rO0）で始まります。トラフィックや保存データでこれを見つけると、簡単な監査ができます。

落とし穴

既知のガジェットクラスを拒否リストにすること。新しい連鎖は定期的に現れます。フレームワークの「セーフモード」フラグが本番でも設定されていると思い込むこと。形式が pickle ストリームか確認せずに、インターネットから機械学習モデルのファイルを読み込むこと。