第2回 「おれがやる」――必然だったサンドボックスの搭載

株式会社フォティーンフォティ技術研究所
取締役 最高技術責任者
金居良治
2009/11/26

閉鎖空間でウイルスの挙動を見る「サンドボックス」。純日本製ウイルス対策ソフト「FFR yarai 2009」のサンドボックス開発でエンジニアは何を目指したのか？（編集部）

　yaraiが持つ複数のエンジン、その成り立ち

　第1回「限界を迎えつつある『パターンマッチング』という手法」で、“パターンマッチングに依存しない”ウイルス対策ソフト、FFR yarai 2009（以下：yarai）の誕生にまつわるエピソードをお話したが、今回はこのソフト開発の技術面についてお話したい。

【関連記事】 シグネチャに頼らず未知の攻撃を検出、FFRが国産対策ソフト http://www.atmarkit.co.jp/news/200904/30/ffr.html 国産ウイルス対策ソフト「FFR yarai 2009」が管理機能を強化 http://www.atmarkit.co.jp/news/200911/12/yarai.html

　yaraiの開発コンセプトは、「ヒューリスティック」と呼ばれる、ウイルスの振る舞いに着目した検出技術である。

　これは前回お話した通り、既存のウイルス対策ソフトが得意とする既知のウイルス検出技術（＝パターンマッチング）では、未知ウイルスがすり抜けてしまうことにより、情報システム被害が発生してしまう。そのため、ウイルス対策ソフトと補完関係になるような製品が必ず必要になる、という考えからきている。

　また、フォティーンフォティ技術研究所（以下：FFR）の主柱業務の1つである研究部門において、さまざまなウイルスの解析を行い、FFR内にウイルスの振る舞いに関するノウハウが蓄積されている。このため、ヒューリスティックによる検出技術で商用製品レベルに達する製品開発ができるという自負もあった。

　現在、yaraiが持っている4つのエンジンのうち、脆弱性対策エンジン、static分析エンジン、HIPSエンジンについては早い段階からリサーチを開始した。

　また、さまざまなセキュリティ製品をリサーチしていく過程で、既存製品は感染後の対策機能について重視していないように思われたため、ウイルスを完全駆除する機能（ヒストリカル・レメディエーション）もyaraiに加えることにした。

　当機能では、自身は攻撃性を持っていないが、次々にウイルスを呼び込みシステムへ実害を与えるような「ダウンローダ型」と呼ばれるウイルスでも、ウイルスの来歴をたどり、関連するウイルスの一斉駆除を実現している。

　そんな中、実装するかどうかについて議論になったのがサンドボックスエンジンである。

　理想の砂場作りとスケジュールのせめぎ合い

　サンドボックスというのは既存の技術であるが、非常に複雑で、開発工数を計算するとスケジュール内の完了が困難であると思われたため、ひとまずリサーチのみ行い、さまざまなサンドボックスの実装方法を調査することとなった。

　サンドボックスとはある種の仮想化で、パソコン内で仮想的な閉鎖空間を作り、検査対象のプログラムを実行、その挙動を見ることでウイルスかどうか判別する手法である。実行によりウイルスに感染したとしても、仮想的な閉鎖空間なので実害はまったく出ない。

　この仮想的な閉鎖空間の作り方にはいくつか手法があり、yaraiに実装すると考えた場合、どの手法が最適かについて調査することがサンドボックスエンジンのリサーチにおける最初の目的となった（このリサーチは、私自身が担当することになった）。

　VMwareのようなCPUの機能を使った手法では、OSのライセンスが別途必要になるためコスト的にペイしそうにない。そこで、Bochsのような「フルCPUエミュレーション」か、「ユーザーランドはそのままプログラムを実行しカーネル内で仮想化を実装」する2つの手法が有力候補になった。

　後者は、ファイルやネットワークといったデバイスへアクセスする部分をフックし、それぞれ仮想的なファイルやネットワークへのアクセスに置き換える手法である。この手法では、ユーザーランド内はネイティブで動作するため、高速であることが大きなメリットであり、実際にこの手法を用いた商用製品もある。

　しかし、デメリットとして、カーネル内のシステムコール・ハンドラやSystem Service Descriptor Table（SSDT）をフックするといったマイクロソフト非公認の技術を使う必要がある。これは、Windowsの将来のバージョンでサンドボックスが動作しない、もしくは新バージョンのサポートが非常に困難になる可能性があることを意味している。また、このフックは実装が難しく、バグが出るとWindows自体が停止してしまう致命的なものになる可能性が高い。フック漏れがあると、容易に悪用できる脆弱性に直結してしまう。商用製品としてはリスキーな方法で、とても実現できそうになかった。

　前者のフルCPUエミュレーションは、CPUをソフトウェア的に実装、仮想的なWindowsを再実装し、その内部で検査対象プログラムを実行するというものだ。技術的には難しいが、実装上の大きな問題はなかった。メリットとして、CPU命令を1つ1つチェックできるという点があり、ウイルス対策に向いているように思われた。

　しかし、デメリットとして動作が遅いということが挙げられる。また、仮想的なWindowsを再実装するという途方もない作業が必要となる。Windowsの再実装とは、Windowsがサポートする膨大な数のAPIをサンドボックス用に書き起こすという作業を意味している。サンドボックス用なので厳密な意味での再実装ではないが、それでもかなり大変な作業になるはずだった。

1/2

Index
「おれがやる」――必然だったサンドボックスの搭載
	Page1 yaraiが持つ複数のエンジン、その成り立ち 理想の砂場作りとスケジュールのせめぎ合い
	Page2 CTO自らが開発 期待できるサンドボックスエンジンの今後

セキュリティを形にする日本のエンジニアたち 連載インデックス

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）