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