著者: 西村 啓佑
はじめまして.リチェルカセキュリティの研究開発課でインターンシップをしておりました西村啓佑です.就労時は東京大学の修士学生をしていました.
本記事では,インターン中におこなった「バグ・脆弱性のRoot Cause検出手法の評価」に関する研究および,私が携わった研究成果の発表(@ Binary Analysis Research 2023)の様子をご紹介します.
あるバグについて「そのバグを引き起こす原因」を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を推定する手法を2つピックアップしてご紹介します.
1つ目の研究は2020年のUSENIX Securityで発表された”AURORA: Statistical Crash Analysis for Automated Root Cause Explanation”です.この研究で提案されたAuroraという手法は,次のようにRoot Causeの推定を行います:
この手法の評価では,実際のバグや脆弱性に対してAuroraを適用し,「推論結果の出力の上位にRoot Causeが含まれているか?」を計算しています.なお,この評価においてファジングにかける時間は2時間となっていました.
2つ目の研究は2021年のAsia CCSにて発表された“Localizing Vulnerabilities Statistically From One Exploit”です.この研究ではVulnLocという手法を提案しており,Auroraと似た方法でRoot Causeの推論を行います.ただし,Auroraとの大きな違いは次の3つです.
なお,この論文での評価もAurora同様著者らがピックアップしたいくつかの脆弱性に対してVulnLocを適用しています.そして,その出力の上位にRoot Causeが存在するかどうかを確認しています.
この2つの研究には以下の共通点があります:
(a) プログラムの構造
(b) バグの場所を(少なくとも)ソースコードレベルで指摘
(c) 評価には著者らが選んだCVE付きのバグなどを使用し,一定時間動作させた結果にRoot Causeが含まれるか確認
我々が調べた限り,上記の構造は多くの類似研究で確認できました.
我々はRCABenchというRoot Causeの推定手法に対するベンチマークの開発と,それを用いた既存研究の評価(特に上述の2つの研究)を行いました.ベンチマークの作成にあたり,既存研究の調査やRoot Causeの実例に対する検討を重ね,既存の評価についてざっくり次のような課題があることを指摘し,解決を提示しています.
このような視点の元に作成したRCABenchを用いて,既存のRoot Cause解析手法の再評価を行ってみました.結果として,例えば次のような発見がありました.
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の推定に関する研究に初期から携わることができました.さらに主著として国際ワークショップに採択され,会社負担で海外の会議に参加することができました.非常に貴重で楽しい経験でした.
このように捗った理由としては研究環境の良さがあげられます.特に
などの要素は非常に価値があるものでした.研究室以外で研究をする経験としてもとても満足しています.同じチームメンバーの皆様,そしてインターンを通じて様々な支援をしてくださった社員の皆様,本当にありがとうございました.