SCAN DISPATCH ：攻撃を発見すると、自動的にパッチを生成・適用するシステムが開発される

　SCAN DISPATCH は、アメリカのセキュリティ業界及ハッカーコミュニティから届いたニュースを、狭く絞り込み、深く掘り下げて掲載します。

国際海外情報

2009年11月10日（火） 16時30分

　SCAN DISPATCH は、アメリカのセキュリティ業界及ハッカーコミュニティから届いたニュースを、狭く絞り込み、深く掘り下げて掲載します。

──

　動作中のCOTS(commercial off-the-shelf)プログラムにHeap Buffer OverflowやIllegal Control Flow Transferが発生すると、問題となる箇所を発見して自動的にパッチを当てるシステムが開発された。

　Defense Advanced Research Projects Agency（DARPA：国防高等研究計画局）のサポートを受けながら、MITとDetermina（現VMware)の協力で研究されたこのシステムは「ClearView」と言い、10月11〜14日に米国モンタナ州で開催された第22回ACM Symposium on Operating Systems Principlesにて「Automatically Patching Errors in Deployed Software」というタイトルの論文で発表されている。

Automatically Patching Errors in Deployed Software論文
http://www.sigops.org/sosp/sosp09/papers/perkins-sosp09.pdf

　脆弱性が発見され、人間がパッチを作って配布し、それを担当者がダウンロードしてデプロイするという現在の手順だと、脆弱性の発見からパッチ当てまでに平均28日間かかると言われているが、このシステムを利用すれば、無防備な期間を大幅に縮小できることになる。

　ClearViewは既に、そのアプローチの弱点を発見してそれをエクスプロイトするテストなどのRed Team評価を受け、その結果は良好である。テストでは、ClearViewで守られたFirefoxに対して10のエクスプロイト攻撃を行ったもの。ClearViewは全ての攻撃を検知・ブロック。攻撃が実際に完了する以前にFirefoxを一時終了して攻撃を未然に防いでおり、10のうち７の攻撃には、効果的なパッチを生成している。テストに使われた10のエクスプロイトは全て、パッチがあたっていないFirefoxには攻撃が成功しているもので、 Memory Management error（Bugzilla Number: 269095、312278、320182）Heap Buffer Overflow （285595、325403）、 Unchecked JavaScript Type（290162、295854 ）、Stack Overflow（296134）、Out of Bounds Array Access（311710）。このうち、Heap Buffer Overflowのエクスプロイトについては、最初のテストでは効果的なパッチを生成できなかったが、再構成後、パッチ生成に成功している。また、False Positiveはひとつもなかった。

　ClearViewは5つのコンポーネントからなる。

(1) 学習：これは、Daikonという学習コンポーネントで、アプリケーションの平常動作中のregistersのvalueとmemory locationなどのインバリアントを観察して「通常」の動作の特性を推論し、これを通常時のモデルとして確定する。

(2) モニタ：out of boundsのmemory writesを検知する Heap Guardと、Illegal Control Flow Transferを検知するDetermina Memory Firewallの2つからなっている。このモニタ・コンポーネントは、excusionが「平常」であるか「エラー」であるかを判断し、エラーと判断されると、バイナリのどこでfailureが発見されたかを記録する。

(3) 関連インバリアントの鑑定：ひとたびモニタ・コンポーネントがfailureを検出すると、システムはまず、failureが発見された箇所の近くで既に存在が確認されているインバリアントをチェックするパッチを挿入することによって、平常のexcusionと、エラーのexcusionにそれぞれ典型的な関連インバリアントを探し出す。これは、平常のexcusionの場合は、それぞれの関連インバリアントがこの方法で満足されるが、エラーのexcusionの場合はそれが違反となるため。

(4) 修復候補の生成：それぞれの関連インバリアントにつき、システムは修復パッチの候補をいくつか生成する。パッチはレジスタやメモリロケーションの値を変更したり、flow of controlを変更したりする。ゴールは、最初のエラーが発生してすぐ後にexcusionを訂正してすることにある。

(5) 修復候補の評価：(4)で生成されたパッチが実際に有効でない場合や、パッチを当てると逆効果な場合などがある。そのためシステムは一度パッチが当てられても、その後、failureが起こったりクラッシュしたりしないかアプリケーションのモニタを行いパッチを評価する。

　ClearViewは、ソースコードの問題箇所の訂正を希望する管理者のために、さらにClearViewは、failureの場所、関連インバリアント、それぞれのパッチ候補が使用した戦略や効果などもリポートする。

　「buffer overunやillegal control transferなどをモニタ・検出する方法は既に研究されているが、ひとたび脆弱性が検出された場合には…

【執筆：米国　笠原利香】
──
※ この記事は Scan購読会員向け記事をダイジェスト掲載しました
購読会員登録案内 http://www.ns-research.jp/cgi-bin/ct/p.cgi?w02_ssw

《ScanNetSecurity》