インターン参加記：脆弱性の原因特定の自動化

著者： 西村 啓佑

はじめまして．リチェルカセキュリティの研究開発課でインターンシップをしておりました西村啓佑です．就労時は東京大学の修士学生をしていました．

本記事では，インターン中におこなった「バグ・脆弱性のRoot Cause検出手法の評価」に関する研究および，私が携わった研究成果の発表（@ Binary Analysis Research 2023）の様子をご紹介します．

Root Cause の検出と評価

Root Causeとは

あるバグについて「そのバグを引き起こす原因」をRoot Causeと呼称します．詳細なRoot Causeが判明することで，デバッグのサポートや，脆弱性に対して重要度に順位付けを行うトリアージが可能になります．実際，ソフトウェアエンジニアリングやセキュリティの文脈で，様々な研究が行われてきました（次の章ではセキュリティ分野でのRoot Cause 検出を行う研究の例を2つご紹介します）．

手始めに，具体的なRoot Causeの例を見てみましょう．次の例は我々の発表した論文からの引用で，CVE-2016-10094の原因になったLibTIFFに存在するバグに関するものです．このバグでは特定の関数のうち，countが4になっている場合のみにoff-by-one errorが生じます．以下がその例と修正パッチです．今回の場合，Root Cause（の場所）は修正箇所になっているif文と考えるのが自然でしょう．詳しくいうなら「当該行においてcount == 4の場合を含めていない」ことといえます．

Root Causeを指摘することの難しさを示す、別の例を見てみましょう．以下に提示するのはLibjpegに存在するCVE-2017-15232の原因となったバグで，以下のListing 2のようなパッチが当てられています．このバグでは output_buf がNULLかつ num_rows が非ゼロである場合にfor ループ内で問題が生じます．したがって，そのような場合の条件チェックとその例外処理を挿入する必要がありました．では，この Root Cause の 場所 はどこでしょうか？（forループ内で num_rows と output_buf が変更されないとして）性能面や一般的な感覚では，forループの前でチェックするのが妥当でしょう．しかしながら，forループ内部でチェックしてもこのバグが修正可能であるため，Listing 3の修正箇所がRoot Causeの場所であるという考え方もできます．

これらの例からわかるように，Root Causeの必要十分な指摘は非常にやっかいです．例えば条件のチェック忘れが問題だとしても，その問題が起きている場所としては様々な候補があるかもしれません．また，その候補となる場所ごとに，条件の表面的な内容も変わるかもしれません．

上記のような背景もあり，我々の知る限りRoot Causeに対するフォーマルな定義はありません．文脈毎に「原因」の捉え方が変わるために，ある一つのバグに対するRoot Causeといっても様々な答え方が考えられます．例えば，あるソースコード中の基本ブロックの指摘を Root Causeとする研究もありますし（特にBug Localizationと呼ばれる），さらに突っ込んで「この変数の値が0未満になること」というレベルで原因推定が求められることもあります．とはいえ，多くの関連研究では半自動的にRoot Causeを扱う（特に場所を検出する）ことに焦点がおかれています．

Root Cause検出手法

この章では，最近のセキュリティの会議に発表されたRoot Causeを推定する手法を2つピックアップしてご紹介します．

1つ目の研究は2020年のUSENIX Securityで発表された”AURORA: Statistical Crash Analysis for Automated Root Cause Explanation”です．この研究で提案されたAuroraという手法は，次のようにRoot Causeの推定を行います：

1. プログラム自身とクラッシュを起こす入力を受理
2. その入力をもとにAFLでファジングを行い，様々なコードパスを通る入力を生成
3. 生成された大量のクラッシュを起こす入力および起こさない入力を比較
4. 統計的に (1)Root Causeの場所 + (2)その場所で問題となる条件 (例: file.c の10行目である変数の値が42以上) の組み合わせの妥当性を推論（妥当さのスコアを計算）
5. (1),(2)の組み合わせのうち，打倒さのスコアが閾値を超えるRoot Cause候補を妥当な順番に出力

この手法の評価では，実際のバグや脆弱性に対してAuroraを適用し，「推論結果の出力の上位にRoot Causeが含まれているか？」を計算しています．なお，この評価においてファジングにかける時間は2時間となっていました．

2つ目の研究は2021年のAsia CCSにて発表された“Localizing Vulnerabilities Statistically From One Exploit”です．この研究ではVulnLocという手法を提案しており，Auroraと似た方法でRoot Causeの推論を行います．ただし，Auroraとの大きな違いは次の3つです．

• ファジングの際に，シードのクラッシュと近いコードパスを通りやすいような入力を生成（この論文で提案された手法で，ConcFuzz (Concentrated Fuzzing) という名前がついている）
• Predicateを使わず，Root Causeの場所のみを候補として出力
• 統計的に妥当そうなRoot Causeにスコアを与える際の計算式

なお，この論文での評価もAurora同様著者らがピックアップしたいくつかの脆弱性に対してVulnLocを適用しています．そして，その出力の上位にRoot Causeが存在するかどうかを確認しています．

この2つの研究には以下の共通点があります：

(a) プログラムの構造

1. 入力として，プログラムとクラッシュを起こす入力を受理
2. クラッシュを起こす入力をシードに，多数の入力をファジングで生成
3. 多くの入力とプログラムから，統計的に正しそうなRoot Cause候補を出力

(b) バグの場所を（少なくとも）ソースコードレベルで指摘

(c) 評価には著者らが選んだCVE付きのバグなどを使用し，一定時間動作させた結果にRoot Causeが含まれるか確認

我々が調べた限り，上記の構造は多くの類似研究で確認できました．

研究成果: RCABenchの開発と評価

我々はRCABenchというRoot Causeの推定手法に対するベンチマークの開発と，それを用いた既存研究の評価（特に上述の2つの研究）を行いました．ベンチマークの作成にあたり，既存研究の調査やRoot Causeの実例に対する検討を重ね，既存の評価についてざっくり次のような課題があることを指摘し，解決を提示しています．

1. Root Causeの定義が曖昧である点 → 必要十分な定義を与えることがほとんど困難であるため，多くの実例を含むオープンなベンチマークを作成した．ベンチマークは様々な種類のバグを含み，それぞれに予め正解となるRoot Causeの位置をソースコードレベルで定義した．
2. Root Cause推定手法には「ファジングで入力を増や」し「多くの例からRoot Causeを推定」するという2ステップがあり，それぞれの評価が必要である点 → ステップを2つに分けるためのインターフェースを定義し，AuroraとVulnLocを分離しそれぞれを組み合わせて評価できるようにした．
3. 特にファジングで入力を増やす際に，時間やシードへの依存性やランダムさを含めた評価が必要である点 → このような変動要因を考慮した評価を行えるようベンチマークを設計した．さらにコンフィグファイルなどでそれらを考慮した実験を行う管理システムを設計した．

このような視点の元に作成したRCABenchを用いて，既存のRoot Cause解析手法の再評価を行ってみました．結果として，例えば次のような発見がありました．

• 「我々が定義したRoot Causeの場所」と論文中の評価で使用されたRoot Causeの場所が異なり，推定の結果が論文の主張とやや異なることがあった．そのため，Root Causeの場所が公開された標準的なベンチマークによる評価が必要．
• ファジングと統計的な推定手法に分離して評価することで，より詳しいRoot Causeの推定手法の比較が可能になった．また，各バグごとに，最も性能が良かったファジングと推定手法の組み合わせは異なった．
• 従来の評価であまり気にしていなかった，ファジングの時間などの要素が結果に影響を与えた．そのため，新規手法の提案では，影響を与えうる様々な要素を考慮した評価が必要．
  • 「ファジングに時間をかければ推定の性能も向上」するとは限らなかった．
  • ファジングのランダム性により，同じ実験でも大きく異なる推定結果が得られることもあった．

RCABench の発表 @ BAR 2023

BARの概要と投稿

Binary Analysis Research (BAR) はNDSSというセキュリティの学会の併設ワークショップです．NDSSは，ビックフォーと呼ばれる情報セキュリティに関する著名でレベルの高い学会・論文誌の一つです．BARは本会議であるNDSSが終わった次の日に別のワークショップとまとめて開催されるため，本会議関係者も多く参加することが見込まれます．そのため，このワークショップで発表することで質の高いフィードバックを得ることができると考えました．

BARでは，バイナリ解析に関する諸技術を幅広く扱います．これはRCABenchの研究のテーマと合致していました．またワークショップということで，完全には終わっていない研究の発表とそのフィードバックを得るという目的に適しています．このような観点から，当ワークショップに狙いを定めて研究を進め，この成果を論文化して正月明けに投稿しました．結果として，論文はアクセプトされたためBAR 2023での発表が決まりました．

旅程・発表

結果の通知がワークショップ開催日の直前だったため，急いでサンディエゴ行きの飛行機（LCCではなくUnited航空を使わせてもらえた）とホテルを予約しました．飛行機往復とホテル代は100%会社に負担してもらいました．

幸いにもNDSSが開催されたホテルが空いており（USENIX参加者が受ける割引の期間は過ぎていたが），そちらに宿泊することができました．サンディエゴのビーチに面した雰囲気の良いホテルで，リゾート気分を味わうことができ満足です．

 

このコテージに宿泊

近くのビーチ（あまりにもエモーショナル）

 
ワークショップでは，様々なトピックの発表がありました．個人的には，シンボリック実行と簡易的な学習を通じて，通信プロトコルの規則を推定する研究発表が面白かったです．

 

BARの発表会場（朝撮影したので，まだスカスカ）

さらに，我々が発表したRCABenchの研究がBest Paper Awardを獲得することができました！まさか受賞できるとは思っていなかったので，急いでチームメンバに連絡しました．

 

Best paper award for RCABench #bar2023 #NDSS2023 (@snagycs) pic.twitter.com/o8iNcYPKTQ

— Aravind Machiry (@machiry_msidc) March 4, 2023

 

記念撮影

なお，以下のページでRCABenchを含むBAR2023にて発表された全ての論文を読むことができます．

https://www.ndss-symposium.org/ndss-program/bar-2023/

おわりに

リチェルカセキュリティでのインターンを通じて，Root Causeの推定に関する研究に初期から携わることができました．さらに主著として国際ワークショップに採択され，会社負担で海外の会議に参加することができました．非常に貴重で楽しい経験でした．

このように捗った理由としては研究環境の良さがあげられます．特に

• 在宅（必要あれば出社して議論）可能
• インターンであっても個人におおきな裁量を与えてもらえる
• Slackなどで非常に技術力があるチームメンバと気軽にディスカッションもできる

などの要素は非常に価値があるものでした．研究室以外で研究をする経験としてもとても満足しています．同じチームメンバーの皆様，そしてインターンを通じて様々な支援をしてくださった社員の皆様，本当にありがとうございました．