2008年05月29日 00:00 [Edit]

バカはバカにならない - 書評 - ファジング:ブルートフォースによる脆弱性発見手法

毎日コミュニケーションズ編集第3部書籍編集1課西田様より献本御礼。

初出2008.05.26;販売開始まで更新

ありそうでなかった一冊。主旨と効用を考えれば、6,090円という定価は決して高いとは言えない。一人一冊とまではいかなくとも、製品としてプログラムを作っているのであれば、チームで一冊持っておいて損はない。


本書「ファジング:ブルートフォースによる脆弱性発見手法」は、ソフトウェアエンジニアリング(と書くとDave Thomasに怒られそうだけど)における、ファジング(Fuzzing)というテスト手法に関して、まるまる500ページを使って解いた一冊。

目次 - MYCOM BOOKS - ファジング:ブルートフォースによる脆弱性発見手法より
日本語版に寄せて
監訳者序文
刊行に寄せて
序文
第I部 バックグラウンド
第1章 脆弱性の発見手法
第2章 ファジングとは?
第3章 ファジングの手法とファズツールの種類
第4章 データの表現と分析
第5章 効果的なファジングの要件
第II部 ターゲットと自動化
第6章 自動化とデータ生成
第7章 コマンドライン引数と環境変数のファジング
第8章 コマンドライン引数と環境変数のファジング:自動化
第9章 WebアプリケーションとWebサーバのファジング
第10章 WebアプリケーションとWebサーバのファジング:自動化
第11章 ファイル形式のファジング
第12章 ファイル形式のファジング:UNIXでの自動化
第13章 ファイル形式のファジング:Windowsでの自動化
第14章 ネットワークプロトコルのファジング
第15章 ネットワークプロトコルのファジング:UNIXでの自動化
第16章 ネットワークプロトコルのファジング:Windowsでの自動化
第17章 Webブラウザのファジング
第18章 Webブラウザのファジング:自動化
第19章 メモリ内ファジング
第20章 メモリ内ファジング:自動化
第III部 高度なファジングテクノロジー
第21章 ファジングフレームワーク
第22章 プロトコル自動分析
第23章 ファズツールのトラッキング
第24章 インテリジェントな欠陥検出
第IV部 未来に向けて
第25章 教訓
第26章 ファジングの未来
索引
監訳者・訳者紹介

それではファジングとは何か?ちょっと長いが、なじみのない言葉でもあると思うので著者自身の説明を引用する。

P. 20
初めてファジングを学ぶ読者は、他人の家に盗みに入ることを想像するとわかりやすいかも知れません。仕事に失敗して人生の裏街道を歩むことになったとしましょう。もしホワイトボックスアプローチを使って盗みに入るとしたら、目的の家に関するすべての情報へのフルアクセスをあらかじめ手に入れる必要があります。実際に盗みを実行するときに状況の調査を行うのではなく、前もって静的に行うのです。これには、間取り図、鍵のリスト、建具の詳細などが含まれます。この方法に長所があることはわかりますが、それは絶対に確実とは言えず、命取りにならないとも限りません。たとえばリビングの窓を割って侵入するのが最適という調査結果が出たとして、実際に入ったら、ショットガンを構えた家主がリビングで待ち構えているかも知れません。
では、ブラックボックスアプローチではどうでしょうか。暗闇にまぎれて家に近づき、最適な入り口を決めるために、家の中を覗き込みながら音を立てずドアや窓を順にテストしていくでしょう。
さて、ファジングを使って侵入するならどうなるでしょうか、ファジングでは、詳細な事前調査も忍び足のテストも行いません。銃を撃ちまくって入れる場所を見つけ出します。侵入プロセスを自動化した、まさにブルートフォース(野蛮な力づく)の脆弱性発見方法なのです。

実に乱暴に聞こえるかも知れないが、この方法は単に脆弱性の発見に留まらず、ソフトウェアの欠陥を発見する方法としてかなり有効でもある。実際私は Perl 5.8 の開発の過程で、この手法を使ってEncodeにあったかなり深刻なバグをいくつかつぶしている。

私が実体験として知っているだけでも、ファジングには二つの利点がある。

一つは、人間の先入観にとらわれないテストができること。この先入観というのはかなりのくせ者で、人手にたよるとどうしてもテストの内容が人間の発想に束縛されてしまう。テスト駆動開発(TDD)の最大の欠点もそこにあったりする。ただし最近ではファジングをテストに組み込むケースも一部ある。たとえば Haskell の QuickCheck はまさにファジングだ。

もう一つは、テストそのものが早く書けること。人手で書いたテストはテスト数が少数なので実行は速いが、そもそもテストを書くのに時間がかかったりするし、どうしても希望的観測がテストそのものに反映されてしまうので「ありえない」ケースはバグ報告があるまで見落とされがちだが、ファジングでは「しらみつぶし」なので、テスト実行時間こそある程度長くとも、テストそのものを書くのは大したことがない。もっともしらみつぶしの範囲を決めておかないと、さすがに長くなりすぎるのだが。この当たりのさじ加減も、本書の課題なのでぜひ確認していただきたい。

このように、ベテランプログラマーであれば多かれ少なかれどこかでファジングしているものなのだけど、著者も指摘する通り、これらの概念は各自バラバラの名前で呼ばれており、また実際の方法も「現場の知恵」に依存する部分が大きかった。本書の登場により、これらが「おばあちゃん」ならぬ「おばちゃんおっさんの知恵」から「業界の常識」になることを期待したい。

本書はこのように実用本意の専門書ではあるが、殺伐とした話題になりがちなだけにユーモアの存在がありがたく感じられる。本書は各章ごとに George W. Bush の「迷台詞」で始まる。たとえば第6章はこうだ。

P. 67
『敵は、革新的な攻撃を仕掛けてきて抜け目ない。我々もだ。敵は米国人に危害を加える武器の開発に余念がない。我々もだ』 -- George W. Bush, Washington, DC (2004年8月5日)

ファジングはある意味「サルにも使える脆弱性発見手法」だ。一家に一冊は多すぎるかも知れないが、一課に一冊はあってもいいのではないか。

Dan the Fuzzing Programmer


この記事へのトラックバックURL

この記事へのコメント
黙るとは思ってませんけどね。
むしろ黙ることなく反論が欲しいです。

ダンコガーイを擁護する気もありませんよ、一応。
最新のエントリーにがっかりしたばかりです。
Posted by ぼんてんまる at 2008年05月31日 00:33
例えヨイショ記事でもアルファブロガーの記事を築いたのは紛れもない事実。
それを妬んでネガティブコメントしか書けないのは醜いですね。
今回僕が気になったのは29日はエントリーがなかったはずなのに、なぜ30日になってから29日の日付でエントリーを書いたのか?
謎です。
ダンコガーイ、何故ですか?
Posted by ぼんてんまる at 2008年05月30日 22:59
また献本で無条件礼賛のヨイショ記事ですか?
自分が恥ずかしくないですか?
Posted by a at 2008年05月27日 22:37
s/決して安くない/決して高くない/
Posted by Kei at 2008年05月26日 12:41
yet anoter typoさん、
ありがとうございます。最後だけは「速い」で正しいのですが、紛らわしいので「実行が」をつけました。
Dan the Typo Generator
Posted by at 2008年05月26日 04:09
s/毎日コミュニケーション/毎日コミュニケーションズ/
s/必要gああります/必要があります/
s/一手にたよると/人手にたよると/
s/少数なので速い/少数なので早いが/
Posted by yet anoter typo at 2008年05月26日 03:58
typoさん、
ありがとうございます。typoがなくなるというのは是たちに創造できません:)
Dan the Typo Generator
Posted by at 2008年05月26日 03:32
s/是たちに/絶対に/
Posted by typo at 2008年05月26日 03:05
s/盗みに入ることを創造する/盗みに入ることを想像する/
Posted by typo at 2008年05月26日 02:48