← DARPA STAC
第 4.3 節

裏付けとなる証拠の収集

RULER：ソフトウェア内のリソース使用の脆弱性を検出するシステム

目次

4.3 裏付けとなる証拠の収集

4.3.1 ダッシュボード

ダッシュボードは、RULER が提供する定型の解析の結果を表示するためのユーザーインターフェースである。現在、RULER のダッシュボードは「Properties」と「Smells」を提供している。プロパティは、分析者が監査の際に把握しておくべき事柄（例：閉世界仮定の違反）であるのに対し、スメルは、分析者が優先して調査すべき、より強いヒューリスティックである。ある結果を計算してダッシュボードに表示するかどうかは、Atlas Toolbox の設定メニューにある Toolbox Commons (Analyzers) サブメニューで制御する。

ダッシュボードビューを開くには、Window -> Show View -> Other… -> Atlas Toolbox -> Dashboard に移動する。

図 9 にダッシュボードビューを示す。最初は、計算済みのプロパティ/スメルの結果だけが表示される。新しいプロパティ/スメルの結果を計算するには、分析者は Search の横のチェックボックスをオンにする。これにより、利用可能なすべてのプロパティとスメルが一覧表示される。プロパティ/スメルを選択し、クリックして展開する。次に Show All Results をクリックすると、結果が計算されて表示される。

ダッシュボードビューのスクリーンショット：左に作業項目のフィルター、右に展開できるプロパティとスメルがあり、System.exit Usage のプロパティが開いている。
図 9. ダッシュボードの結果

ダッシュボードが提供する「Properties」と「Smells」は次のとおりである。

1. 循環的複雑度

ダッシュボードは、メソッドの循環的複雑度を提供する。このスメルを使うと、循環的複雑度の高いメソッドが検出される。

2. 再帰関数

ダッシュボードは、与えられたアプリ内の再帰関数に注意を向けさせるスメルを提供する。このスメルは、再帰関数の存在を分析者に知らせる。分析者は、この知識をほかのツール（LCG、PCG など）と組み合わせて、脆弱性があるかどうかを判断できる。

3. System.exit の使用

ダッシュボードは、System.exit を使用しているメソッドを見つけられる。System.exit() は、アプリの実行を終了させ、すべてのスレッドを停止させる。これにより、クライアントのインスタンスが永久に待ち続けることがあり、分析者の注意が必要である。このスメルはまさにそれを行う。

4. 自己参照型データ構造

ダッシュボードは、与えられたアプリ内の自己参照型データ構造を見つけるスメルを提供する。自己参照型データ構造は同じ型のフィールドを持ち、ループ内で使われると非常に急速に大きくなりうる。これにより、そのようなデータ構造に格納された情報を処理するコスト（空間と時間）も増える。実際に、我々はこれらが脆弱性、特に AC 脆弱性の原因となるのを観察した。したがって、分析者には自己参照型データ構造の存在を知らせるべきであり、それがこのスメルの役割である。

5. 深くネストしたループ

ダッシュボードは、（局所的な）ネストの深さが 4 以上のループを見つけるスメルを提供する。ネストの深さは、すべてのループについてループカタログビューでも提供される。

6. 無限ループ

ダッシュボードは、特定の種類の無限ループ（終了条件の結果が定数であるもの、例：while(true)）を見つけるスメルを提供する。無限ループの存在は、潜在的な AC 脆弱性の明らかな兆候である。したがって、分析者にはその存在を知らせるべきである。分析者はループカタログを使ってそれらを見つけることもできる。これはよく使われるスメルであるため、定型の解析として提供されている。

7. Executors.newFixedThreadPool の使用

ダッシュボードは、Executors.newFixedThreadPool の呼び出しを見つけるスメルを提供する。固定サイズのスレッドプールは、AC 脆弱性にとって関心の対象である。すべてのスレッドを使用中のままにしておけると、無害なリクエストがブロックされることにつながりうる。

8. 順序を保持するデータ構造

JDK は、順序を保ちながらデータを格納するのに使えるさまざまなデータ構造（List、TreeSet など）を提供している。ダッシュボードは、与えられたアプリ内のそのようなデータ構造を見つける。そのようなデータ構造自体が脆弱性の原因となるわけではないが、我々は、データ構造に格納された要素が処理される順序に依存する脆弱性を観察した。そのような脆弱性にとって、順序を保持するデータ構造の存在は必要条件である。このスメルはそのような脆弱性を分析者の視野に入れ、分析者は、IPCG（PCG ビルダー）などのツールを使ってこれらのデータ構造を処理するコードを分析することで、この種類の脆弱性の存在を確認できる。

注：配列は考慮しない。

9. リフレクションの使用

ダッシュボードは、アプリ内で java.util.reflection を介した Java リフレクションの使用をすべて見つけるスメルを提供する。リフレクションはメソッドの呼び出しやデータの受け渡しを難読化するのに使えるため、これは隠れた振る舞いについて分析者に注意を促す。

10. ループ本体での Random の使用

ダッシュボードは、Random API を参照するループを見つけるスメルを提供する。これは、ループの反復回数の上限が random を使って難読化された STAC のチャレンジアプリケーションに対応して開発された。たとえば、次のループは、内側のループの条件を省いた場合と同じ結果を計算するが、内側のループの 4 分の 1 が 2 つ目の条件で失敗するため、実行時間がわずかに長くなる。このパターンは、ループの上限を単調であると分類することを妨げ、見かけ上のループのネストを深くする。したがって、このスメルは異なる目的を果たす。脆弱なループを検出するのではなく、脆弱ではないが誤警報を引き起こしやすいループを見つけるのに役立つ。そのようなループはその後の解析から除外すべきであり、このスメルはそれを助ける。

while (i < length) {
    while (i < length && random() < 0.75) {
          i++;
    }
}

11. アプリケーションのエントリポイント

ダッシュボードは、与えられたアプリへのエントリポイントとなるすべてのメソッドを見つける。エントリポイントは通常、攻撃者とアプリの間の相互作用の箇所となる。そのため、エントリポイントから解析を始めるのが一般的である。このプロパティは、分析者のためにアプリケーションのエントリポイントを見つけるために計算される。

アプリは通常さまざまな Web フレームワークを使用するため、Web フレームワークのハンドラもエントリポイントとして考慮しなければならない。RULER は、ヒューリスティックを用いて Web フレームワークのハンドラを認識する。具体的には、RULER は次のものをアプリケーションのエントリポイントとして認識する。

  • アプリ内の Java の main メソッド
  • javax.servlet.http.HttpServletRequest（Java サーブレットのリクエスト）
  • com.sun.net.httpserver.HttpHandler（Sun の HTTP リクエストハンドラ）
  • Netty の channelRead0() メソッド（Netty フレームワーク）
  • org.springframework.web.bind.annotation のアノテーションが付いたメソッド（Spring フレームワーク）
  • spark.Route() をオーバーライドするメソッド（Spark フレームワーク）
  • java.net.Socket() の accept() メソッド（ソケット接続）

12. クラスローダーの使用

ダッシュボードは、リフレクションの使用と同様の理由で、クラスローダーの呼び出しを見つける。クラスローダーは、クラスの使用の難読化に関わりうる。

13. ネイティブコードの使用

ダッシュボードは、アプリ内のネイティブメソッドの使用をすべて見つけられる。ネイティブコードは潜在的に何でもでき、純粋にバイトコードに基づく解析からはそれ以外の方法では見えないため、これは隠れた振る舞いを示している可能性がある。

14. Java プログラムのエントリポイント

ダッシュボードは、与えられたアプリ内のすべての Java の main メソッドを見つけられる。

15. シリアライズの使用

ダッシュボードは、Serializable インターフェースの使用をすべて見つけられる。実際に、我々は、シリアライズ可能なオブジェクトの不適切な処理が脆弱性の原因となることを観察した。たとえば、XML ボムは、アプリが悪意のある XML 文書をシリアライズしようとするときに発生する、よく知られた攻撃である。このスメルは、アプリ内にシリアライズ可能なオブジェクトが存在することを分析者に知らせる。これにより既知の攻撃が検討の対象に入り、それらを最初にテストすべきである。

16. プロセスの使用

ダッシュボードは、アプリケーションがシェルコマンドを実行できるようにするすべてのメソッドの呼び出しを見つけられる。これは、分析者にとって関心のある隠れた振る舞いを表している可能性があるためである。

4.3.2 PCG ビルダー

PCG ビルダーのインターフェースは、複数の関数にわたってイベントを選択し、手続き間の PCG（IPCG）を計算するためのユーティリティである。基本的な使い方としては、関心のあるイベントを選択して「Show PCG」ボタンを押すだけでよい。高度な使い方としては、分析者は、追加のコンテキストを得るために祖先関数と展開可能な関数を選択できる。

PCG ビルダーのビューを開くには、Window -> Show View -> Other… -> Atlas Toolbox -> PCG Builder に移動する。

PCG ビルダーのスクリーンショット：制御フローのイベント、それを含む関数、祖先関数、展開可能な関数の列と、例外的な制御フロー、人間の利用者、拡張された構造のオプションがある。
図 10. PCG ビルダー

Exceptional Control Flow は、例外処理による制御フローパスを表す。PCG の計算に例外的な制御フローパスを含めるには、このオプションを選択する。

Human Consumer：IPCG を作成すると、関数のコールサイトがイベントとして含まれる。制御フローパスの定義に従えば、関数の return ノードは、コールサイトを含む関数へリダイレクトして戻すべきである。しかしこれは、人間の分析者に認知的な負担をかける不要な情報を生む。これを減らすため、我々は、リダイレクトのエッジを含めず、IPCG を人間の利用者により適したものにするオプションを提供する。

Extend Structure：作成された PCG には、選択したイベントに対応する関連した制御フローパスを形成する、制御フローのノードとエッジが含まれる。これらのイベントはさまざまな関数に含まれ、関数自体は異なるクラスに含まれ、クラスは異なるパッケージに含まれる、というように続く。これが PCG の拡張された構造である。分析者の好みに応じて、拡張された構造を表示する必要はない。このオプションは、構造の拡張を有効/無効にする。

祖先関数とは、選択したイベントを含むいずれかの関数の逆コールグラフに存在する関数である。祖先関数を選択すると IPCG のサイズは大きくなるが、結果に呼び出しのコンテキストが追加される。

展開可能な関数は、イベントへ至るパスに沿って、祖先関数内のコールサイトを追加する。祖先関数を選択したら、「Expandable Functions」の下のチェックボックスを使って関数を展開できる。イベントにつながる関数へのコールサイトは、IPCG における暗黙のイベントである。既定では、明示的なイベントを含まない関数では暗黙のイベントは省略され、その関数全体が、得られる PCG 内の 1 つのノードに折りたたまれる。ただし、これらの折りたたまれた関数は、PCG ビルダーのインターフェースで展開でき、展開した各ノードについて暗黙のイベントの PCG を表示できる。

PCG ビルダーのメニューバーには、新しい PCG インスタンスのボタンもあり、これは新しいタブを作成する。これにより、PCG ビルダーは IPCG の複数のインスタンスの状態を保持できる。

4.3.3 ループとサブシステムの相互作用ビルダー

ループとサブシステムの相互作用ビルダーにより、分析者はループの集合と関数の集合を入力として指定し、入力した関数の少なくとも 1 つと呼び出しによる相互作用を持つループだけを選択できる。たとえば、コレクション API と相互作用するループの集合を選択するには、分析者はまず、絞り込む対象のループを表示して選択し、それらを左側のペイン「Loops」に追加する（下の図を参照）。関数を追加するには、分析者はシェルコマンドを実行してまずコレクションサブシステムのすべての API を表示し、表示されたノードのすべて（または一部）をビルダーの右側のペイン「Functions」に追加する。「Show Loops Interacting with Subsystem」をクリックすると、コールグラフを介して選択したループと相互作用するループが表示される。

show(nodes("COLLECTION_SUBSYSTEM").contained.nodes(XCSG.Method))

ループとサブシステムの相互作用ビルダーを開くには、Window -> Show View -> Other… -> Atlas Toolbox -> Loop Subsystem Interaction Builder に移動する。

ループとサブシステムの相互作用ビルダーのスクリーンショット：左に 4 つのループ、右にコレクション API の関数が並んでいる。
図 11. ループとサブシステムの相互作用ビルダー

4.3.4 デコンパイラビュー

デコンパイラビューは、バイトコードの理解を深めるために、Jimple コードとデコンパイルされたソースコードの間の双方向の対応を提供する。メソッドに対応する Jimple コードの一部または Atlas のグラフ要素を選択すると、デコンパイラビューは、選択した Jimple コードまたは Atlas のグラフ要素に対応するデコンパイルされたソースコードを出力する。

このビューは、Java バイトコードのデコンパイルに Class File Reader（CFR）ツールを使用する。このビューはメソッド単位で動作する。すなわち、分析者がメソッドを選択すると、そのメソッドのソースコードだけをその場でデコンパイルする。図 12 に、CFR デコンパイラビューのスクリーンショットを示す。

Jimple エディタと、その下にある CFR デコンパイラビューのスクリーンショット：選択したメソッドのデコンパイルされた Java ソースが表示されている。
図 12. CFR デコンパイラビュー

4.3.5 フィルタービュー

フィルタービューにより、分析者は、ノードとエッジの「ルート集合」を入力として指定し、その集合にフィルターを選択的に適用して、元の入力の部分集合を得られる。このインターフェースは、RULER が提供するフィルターを読み込み、与えられた入力集合にどのフィルターを適用できるかを自動的に判断する。

フィルタービューを開くには、Window -> Show View -> Other… -> Atlas Toolbox -> Filter View に移動する。

フィルタービューのスクリーンショット：左にループヘッダーのフィルターツリー、右に Loop Monotonicity フィルターの説明とパラメータがある。
図 13. フィルタービュー

詳細は、次のサイトで参照できる：https://ensoftcorp.github.io/toolbox-commons。

4.3.6 Smart Views

RULER は現在、この節に（タイトルで）挙げる Smart Views を提供している。Smart View を開くには、Atlas -> Open Atlas Smart View メニューを使用する。次に、Smart View の下部にあるコンボボックスを使って特定のビューを選択する。Smart Views は、ほかのグラフやテキストベースの Jimple エディタでの選択に応答する。提供している主な Smart Views は次のとおりである。

  • Code Painter：Code Painter のインターフェースとコントロールパネルは、Smart View の振る舞いとスタイル情報をさらに細かく制御できる、高度な Smart View の実装である。2 つの新しい概念を導入する。1) Code Painter と Code Painter のコントロールパネル、2) カラーパレットである。Code Painter のインターフェースは、新しい Code Painter の Smart Views を定義するための拡張可能なインターフェースである。Smart Views は、選択と Code Painter のコントロールパネルによって制御される。カラーパレットはスタイルのロジックであり、個別に適用することも、Code Painter ビューの有効なスタイルの 1 つの層として適用することもできる。
  • Enhanced Loop Call Graph：プログラム内のループを、ループヘッダーとコールサイトの観点から概観する。拡張ループコールグラフのエッジは、1) CallSite から呼び出し先となりうる Method へ、2) Method からその本体内の Loop と CallSite へ、とつながる。エッジはネストの階層を表す。たとえば、Loop 内の CallSite には、Method > Loop > CallSite というパスに沿って到達できる。関連項目：LCG。
  • Loop Call Graph (LCG)：プログラム内のループを、コールグラフの観点から概観する。関連項目：LCG。
  • Control Flow Graph (CFG)：Method 内の制御フローを概観する。
  • Control Flow Graph with Exceptional CF (Ex CFG)：Method 内の制御フローと例外的な制御フローを概観する。
  • Projected Control Graph (PCG)：イベントに関して PCG を作成する。関連項目：PCG。
  • PCG: Events = {Loop Headers, CallSites to LCG}：ビュー Projected Control Graph (PCG) と同様だが、ループコールグラフ（LCG）に基づくイベントを自動的に含める。
  • Taint：テイントのエッジに基づいて依存関係を表示する。RULER は現在、テイントのエッジを 1) 局所的なデータフローと、2) JDK ライブラリに解決される CallSite について、実引数から CallSite へのエッジ（これにより CallSite を演算子として扱う効果がある）として定義している。関連項目：テイント。
  • Taint -> PCG：テイントに基づく部分グラフが与えられたとき、PCG を作成する。関連項目：Projected Control Graph (PCG)、テイント。
  • PCG + Condition Flows：PCG に条件のデータ依存を含める。関連項目：Projected Control Graph (PCG)、テイント。
  • Loop Terminating Conditions (LTCs)：LTC を参照。
  • Loop Termination PCG：ループの構造をすばやく理解するのに役立つ射影制御グラフを作成する。関連項目：Projected Control Graph (PCG)
  • Loop Termination Dependence Graph (TDG)：与えられたループの終了条件のデータフロー依存関係を表示する。
  • Subsystem Interaction View：ループ、メソッド、制御フローノード、またはコールサイトが、事前に定義されたサブシステムの一部と持つ相互作用を理解するのに役立つ。関連項目：サブシステムの相互作用のタグ付け。
  • Subsystem Interaction PCG View：ループまたはメソッドが、アプリのほかの部分、または JDK の API の事前に定義された機能分類（サブシステム）の 1 つと持つ相互作用を理解するのに役立つ。関連項目：サブシステムの相互作用のタグ付け。
  • Loop Nesting View：選択したメソッド内のループ間、または選択したループヘッダー内に含まれるループ間のネストの関係を理解するためのビューである。
  • Reachable Loops View (From/To Input)：選択したアプリケーションの入力または変数から到達可能なループ、またはそれらへ到達可能なループを特定するためのビューである。
  • Loop Body View：選択したループ内の制御フローを理解するためのビューである。