ソフトウェアに対する脆弱性の混入を防止するには、開発ライフサイクルの全体に渡って脆弱性検出のための仕組みを適切に取り入れることが不可欠です。本特集では、IPA セキュリティセンターの協力の下で、脆弱性検出手法のひとつである「ファジング」について、その特徴や効果、導入に向けた留意点などを解説します。

最終回となる今回は、大手ソフトウェアベンダーによるファジングの活用例として、MicrosoftおよびAdobe Systemsによる事例を紹介します。

Microsoft SDLにおけるファジングの活用

本特集の第1回で、ファジングを巡る業界動向としてMicrosoft（以下、MS）が積極的な取り組みを実施していることに触れました。同社ではファジングだけでなく、ライフサイクル全体にわたってソフトウェアの脆弱性を軽減させる開発プロセスを構築・採用しており、外部向けにもその内容を「Microsoft SDL（Secure Development Lifecycle）」として公開しています。SDLでは、「⁠検証」のフェーズに適用するプラクティスのひとつとしてファジング（SDLの呼び方では「ファジーテスト⁠」⁠）が採用されています 。

そこで今回、日本マイクロソフト株式会社でチーフセキュリティアドバイザーを務める高橋正和氏に、ファジングを含めた同社の取り組みについてお話を伺いました。

MSにおけるセキュリティ対策で特筆すべき点は、大小あらゆる製品の開発にSDLの導入を徹底しているということです。高橋氏によれば、「⁠SDLというのはこれまでにMSが痛い目に遭いながら積み上げてきたベストプラクティス」であり、本当の意味でセキュリティを保証するために必要なものだとのことです。図2は、SDLに至るまでの同社の取り組みの概要をまとめたものです。

ファジングが本格的に導入されたのはWindows Server 2003の開発においてセキュリティプッシュ（全開発者を動員したセキュリティ検査）が実施されたころからだそうですが、この図を見ても、ファジングだけが特別な存在というわけではなく、開発ライフサイクル全体に対する取り組みの中の一要素であるということがよく分かります。

「ファジングはSDLの中の重要な要素ではありますが、これ単体で何ができるかということではなく、あくまでも開発ライフサイクル全体で考えることが前提になっています。そういう意味では、"ファジングでバグを無くす"という考え方だと誤解を生むかもしれません。あくまでも"品質を高める"という意識で、そのためのひとつの手段として位置づけるべきものだと思います」

高橋氏は、ライフサイクル全体でセキュリティを考える一例としてMS Office 2007におけるファイルフォーマットの変更を挙げました。ファジングを利用すれば、バイナリファイル中の不正なコードを実行してしまうなどといった脆弱性はある程度発見できるかもしれません。しかし、それでも検査漏れを完全に防ぐことはできません。そこで、そもそもファイル中にバイナリデータが入りにくい構造を採用するという、設計の段階から安全性を高めるアプローチを取ったそうです。

ファジングによって問題が発見できた場合にも、単に場当たり的にその問題に対処すればいいというわけではなく、なぜその段階まで問題が発見できなかったのかを検証しなければならないと、高橋氏は指摘しています。もっと早い段階で問題を発見できるように、あるいは最初から問題が入り込まないように、ツールやプロセスを見直していかなければならないということです。実際、MSでは半年に1回のペースでSDL自体のアップデートを実施しているそうです。

ファジングに関連するアップデートとしては、導入当初からSDL 2.2（2005年）まではファイルパーサーやRPC（Remote Procedure Call）インタフェースがおもなファジングの対象でしたが、SDL 3.0（2006年）からはActiveXコントロールまで対象が拡張されています。そしてSDL 5.0（2009年）からはすべてのネットワークインタフェースとパーサーがファジングの対象になりました。このように、市場と攻撃方法の変遷に応じてファジングの対象が拡張されている点も興味深いところです。

高橋氏は、「⁠製品のライフサイクル全体で考えないと、ファジングの使いどころは難しい面もありますが、ウォークスルーチェックが難しい非機能要件のテストにおいては、最低限実施すべき検査」だと語っています。特にソフトウェアにネットワークの要素が当たり前に含まれるようになってからは、問題の発生要因のランダム性が高まっているため、「⁠ファジング程度のことは当たり前に実施しているようでなければ、セキュリティ上の脅威には対抗していけません」と強く語りました。

Adobe Flash Playerに対するファジングの実施

続いてAdobe Systems（以下、Adobe）によるファジングの活用事例を紹介しましょう。AdobeのPlatform Security StrategistであるPeleus Uhley氏は、CanSecWest 2012において同社製品のセキュリティ向上への取り組みに関する講演を行っています。その中で、Flash PlayerへのSWFファイルを利用した攻撃に対する脆弱性をテストするために、大規模なファジングを実施したことが紹介されました。

Flash Playerに対するファジングは、Googleの協力の元で以下のように行われたそうです（その様子はGoogleのセキュリティチームによるブログでも紹介されています⁠）⁠。

• "corpus distillation"方式を採用
• Web上の20テラバイトのSWFファイルを元に、約20000ファイルの"最小セット"を生成
• 最小セットの生成には2000CPUを使って1週間を要した
• 最小セットおよびそこから（ビットフリップなどによって）少しずつ変化させたファイルを使い、3週間にわたってファジングを実施
• テストはファジングの専門家であるTavis Ormandy氏が担当

"corpus distillation"は、大量のソースコード（この場合はSWFファイル）から、それらのコードの特性を網羅的に含んだ最小セットを自動生成し、それをファズとして利用する手法です。チェックできるパターンの網羅性を下げずにファズの数を現実的なレベルまで絞り込むことができるというメリットがあります（"corpus distillation"についてはTavis Ormandy氏のプレゼンテーション資料で詳しく解説されています⁠）⁠。Flash Playerに対するファジングでは、最終的に80の問題が発見され、修正パッチの開発が行われたとのことです。

もちろん、Adobeでもファジングだけを単独で実施しているわけではありません。同社ではSecure Product Lifecycle（SPLC）として開発ライフサイクル全体にわたるセキュリティ向上のための取り組みを定めており、すべての製品の開発に適用しているとのことです。そして、ファジングはその中のひとつの重要な要素として活用されています。

IPAによる「ファジング活用の手引き」

大手企業でファジングの採用が進む一方で、日本においてはまだ十分に普及しているとは言えない現状があります。そこでIPAでは、2011年8月より『ソフトウェア製品における脆弱性の減少を目指す「脆弱性検出の普及活動⁠」⁠』のひとつとしてファジングの啓発を始めており、2012年3月にはファジングの活用方法などをまとめた「ファジング活用の手引き」および「ファジング実践資料」を公開しました。

「ファジング活用の手引き」では、ファジングの特徴や効果、導入に向けたポイントなどを挙げた上で、実際にIPAによってファジングを実践し、その方法や得られた結果などを紹介しています。また「ファジング実践資料」では、ファジングツールの使い方や生成されるファズの例、ツールを使わずにファジングの結果を再現する方法などを紹介しています。ファジングの実施に必要となる具体的な手順がまとめられているため、開発ライフサイクルへのファジングの導入に向けた第一歩として活用できるでしょう。