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に置き換え、ウィン
ドウの生成個数のチェック
– ネットワークアクセスの際に、接続先のマシン
名やポート番号を調べる。
テクニック
著者は２つの修正方法をとっている。
置き換え
個所
Class
Method
長所
短所
簡単
FinalやInterface
には不可能
どのようなもの 置き換え操作に
でもOK
時間がかかる
Class-level Modification
危険なクラスを、事前に検査を行うその子クラス
で置換する方法。
– Constant poolのクラス名を置き換える
Method－level Modification
危険な呼び出しを行うメソッドを、事前に検
査を行う別なクラスメソッドに置換する方法。
– 例えば、下記のように変換する
void foo(Thread t, int i) {
void foo(Thread t, int i) {
Safe$Thread
t.setPriority(i);
}
.setPriority(t, i);
}
Method-level Modification(2)
バイトコードを見比べると
void foo(java.lang.Thread, int)
void foo(java.lang.Thread, int)
aload_1
aload_1
iload_2
iload_2
invokevirtual #2
invokestatic #2
<void setPriority(int)>
return
<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
4%
Safe$AppletContext for URL Spoofing
5%
Safe$AppletContext for Sound Object Control
55%
筆者の結論
ある種の危険な動作をあらかじめ予防し、
ユーザーがそれをカスタム化できる変換テ
クニックを提案した。
バイトコード変換はProxy Serverで行ったが、
将来的にはクラスローダで行うべきである。
意見
CPUやメモリのResource Control等が問題と
して提起はされているものの、全く解決さ
れていない。
Java2のAccess Controlを細かく設定できるよ
うに拡張したほうが、性能がよくなり、実装
上のバグも少なくなる。
JavaのReflection機能を使用しても大丈夫？
© Copyright 2024 ExpyDoc
