Java Bytecode Modification and Applet Security 2001/05/16 Mizukami Tatsuo
概要 信頼できないJavaのプログラムをバイトコードの変換によってより安全に実行する。 そのためのテクニックを発表。
注意 著者はJava2以前の仕様を前提にしている。 Java2の正式リリースは1998年12月8日 この論文は98にSubmit
問題背景 筆者がいうJavaアプレットのセキュリティの主な問題 具体的にいうと…… Denial of Service Attack Disclosure of Confidential Information Attack Spoofing Attack Annoyance Attack 具体的にいうと……
Denial of Service Attack CPUやメモリ等の占有 大量のウィンドウの表示 ファイルシステムの占有
Disclosure of Confidential Information Attack Java Applet内で得られた情報をもとのサーバーに漏らす。 ファイルアクセス可能なアプレットA, Bがあり、ネットアクセス不可能なAがネットアクセス可能なBとファイルを中継して、情報を漏洩する。
Spoofing Attack 間違った情報を表示して、ユーザーに不適切な選択をさせる。 これへの対処は難しい。 論文では出力情報に対するインターフェースを強固にし、その引数チェックを行っている。
Annoyance Attack ユーザーにとって不快な操作を行う。 音を永久に鳴らしつづける 不快な画像を表示 大量のWindowを表示するのもこちらにも分類できる
別な分類 Securityに対する攻撃は別な文献(Securing Java)では次のように分類している System Modification Invasion of Privacy Denial of Service Antagonism
解決方法 ダウンロードするクラスファイルを解釈して、危険な操作を行うクラスの修正or置換を行う。 WindowクラスをSafe$Windowに置き換え、ウィンドウの生成個数のチェック ネットワークアクセスの際に、接続先のマシン名やポート番号を調べる。
FinalやInterfaceには不可能 テクニック 著者は２つの修正方法をとっている。 置き換え 個所 長所 短所 Class 簡単 FinalやInterfaceには不可能 Method どのようなものでもOK 置き換え操作に時間がかかる
Class-level Modification 危険なクラスを、事前に検査を行うその子クラスで置換する方法。 Constant poolのクラス名を置き換える
Method－level Modification 危険な呼び出しを行うメソッドを、事前に検査を行う別なクラスメソッドに置換する方法。 例えば、下記のように変換する void foo(Thread t, int i) { Safe$Thread .setPriority(t, i); } void foo(Thread t, int i) { t.setPriority(i); }
Method-level Modification(2) バイトコードを見比べると void foo(java.lang.Thread, int) aload_1 iload_2 invokevirtual #2 <void setPriority(int)> return void foo(java.lang.Thread, int) aload_1 iload_2 invokestatic #2 <void setPriority(Thread,int)> return
Method-level Modification(3) 修正前のコンスタントプール
Method-level Modification(4) 修正後のコンスタントプール
実装 サーバーとクライアントの間にバイトコードの修正を行うプロクシをおく。 長所 短所 実装が楽。 簡単にブラウザ等の拡張が可能。 余計な時間が必要 クラスファイルかどうかわからない時がある。
性能評価 実際にPythonでProxy serverを作成
仮想性能評価 仮にCでProxy serverを作成すると
実行性能評価 修正されたコードの性能評価 Safeguarding code Overhead Safe$Frame for Window Attack 4% Safe$Socket for Network Accesses Safe$AppletContext for URL Spoofing 5% Safe$AppletContext for Sound Object Control 55%
筆者の結論 ある種の危険な動作をあらかじめ予防し、ユーザーがそれをカスタム化できる変換テクニックを提案した。 バイトコード変換はProxy Serverで行ったが、将来的にはクラスローダで行うべきである。
意見 CPUやメモリのResource Control等が問題として提起はされているものの、全く解決されていない。 Java2のAccess Controlを細かく設定できるように拡張したほうが、性能がよくなり、実装上のバグも少なくなる。 JavaのReflection機能を使用しても大丈夫？