Javaのデシリアライゼーションの問題を見つける方法は?

exploit java serialization
Javaのデシリアライゼーションの問題を見つける方法は?

私はJavaコードでのデシリアライゼーションの問題を発見できるようにしたいと思います。 何を探すべきですか? たとえば、あるJavaコードが「http://slightlyrandombrokenthoughts.blogspot.com/2008/12/calendar-bug.html[java calendar bug]」を悪用しようとするかどうかをどのように判断しますか? 私はJavaプログラマーではありませんが、シリアル化とOOPの背後にある概念を理解していることに注意してください。 私はいくつかの安全性チェック(コンパイラ警告ツールのようなもの)を実装しようとしています。

*編集:*コメントに基づいて質問を少し変更したい:「信頼できない」と分析されたすべてのコードを検討します。潜在的な危険を評価する方法はありますか? つまり、逆シリアル化のバグに関して、コードAはBよりも危険だと言えますか? 何を探すべきですか?

  7  0


ベストアンサー

まず、セキュリティの脅威を判断するには、コンテキストを理解する必要があります。 (「信頼」について話すとき、私は少しショートカットを取っています。 私は故意に悪意のある話をしています)

シリアル化されたデータが同じ信頼で作成され、保持され、読み取られた場合、実際の問題はありません(標準的なバグ以外)。 機密情報を記述する場合、シリアル化されたデータも機密であることに注意してください(明らかなようですが、そこにはかなりの間接性があります)。

何らかの理由でシリアル化されたデータが信頼できない場合は、考慮すべきことがもう少しあります。 再作成されたオブジェクトの内部構造は「異常な」場合があります。 データに一貫性がない場合があります。 個別の可変オブジェクトを共有している場合があります。 逆シリアル化は、無限ループ、または宇宙の熱死の前にたまたま完了できない非無限ループを引き起こす可能性があります。 そしてもちろん、データは嘘かもしれません。

信頼性の低いコードで使用されるライブラリコードを記述している場合、事態はさらに面白くなります。

「カレンダーバグ」(および同様の)の場合、悪意のあるデータと悪意のあるコードで任意のストリームを逆シリアル化することです。 Javaセキュアコーディングガイドラインでは、カスタム「readObject」メソッド内で(「Java2セキュリティモデル」を使用して)セキュリティチェックを行うことを提案しています。

デシリアライズ可能なオブジェクトの側から見ると、物事はよりトリッキーです。 ObjectInputStream`が readObject`、 readUnshared、` defaultReadObject`、 readFields`を介して提供するオブジェクト、またはデフォルトのデシリアライゼーションだけが、悪意のあるコードによってキャプチャされた参照を持つか、最終クラス以外の場合、悪意を持ってサブクラス化されます。 オブジェクトは、部分的に初期化されている場合、逆シリアル化中にも使用される場合があります。 逆シリアル化は、逆シリアル化されたクラスの「実際の」コンストラクターを呼び出しません( `readObject /` readObjectNoData`は一種の擬似コンストラクターで、 `final`sを設定できません)。 それはすべて悪夢のようなものなので、おそらく機密クラスをシリアライズ可能にしたくないでしょう。

シリアル化と逆シリアル化の実装に多くの脆弱性があります。 自分で実装する場合を除き、これについて実際に心配する必要はありません。

5


うーん…​ あなたの質問は少し一般的です。 この記事ですか? Javaのシリアル化アルゴリズムについてですが、メインページが現在ダウンしているように見えるため、Googleのキャッシュからです。

2


Javaの既知のセキュリティホールを悪用するコードを無効にする最善の方法は、バグを修正するJavaバージョンにアップグレードすることだと思っていました。 そして、次の最良の方法(シリアル化関連のバグに対処するため)は、不明/未検証/安全でないソースからのすべてのシリアル化されたデータを疑わしいものとして扱うことです。

Javaコードのセキュリティバグを分析して問題を見つけようとするのは簡単ではなく、使用されて悪用される可能性のあるJavaメカニズムを深く理解する必要があります。 特にゼロデイセキュリティホールのエクスプロイトを探している場合は、(一般的に)試みられたエクスプロイトを見つけようとするのはさらに困難です。 他の潜在的なベクトルがあることに留意してください。

(Javaに未知のセキュリティホールを見つける簡単な方法があれば、Sunや他のセキュリティ研究者はすでにそれらを使用しているに違いない。)

1


Javaオブジェクトをシリアル化して別のアプリケーションに転送する場合、アプリケーション間で共有されるキーを使用してオブジェクトに署名することを検討してください。 中間者攻撃から身を守るには十分なはずです。

検証問題の核心に戻ると、検証は汎用言語では非常に困難です。 このトピックに関する科学出版物を探す必要があります。 最も一般的に適用される手法は、http://en.wikipedia.org/wiki/Sandbox_%28computer_security%29 [sandboxing]です。 2番目のアプローチは、言語を制限し、危険なコマンドの実行を許可しないことです。たとえば、http://developer.yahoo.com/yap/guide/caja-support.html [Yahoo Caja library]はこの手法を使用します。

1


タイトルとURLをコピーしました