セキュリティ関連バグと一般的なバグの比較

　Linuxカーネルの開発作業に関する意見交換が，最近激しい議論に発展した。ソフトウエアのセキュリティ関連バグは一般的なバグと区別して扱うべきか，という内容の議論だ。セキュリティ関係のメーリング・リスト「Full Disclosure」で紛糾したテーマから派生した。議論には，セキュリティ・ホール情報の開示が最適なユーザー保護策かどうかを疑い，セキュリティ・ホールの発見者と修正者がそれ以外のバグ撲滅に貢献した人より過剰に賞賛されている，と主張する人々が登場した。筆者は個人的に，議論の対象にはなっていないものの重要な比較要素が二つ存在すると考えている。

セキュリティと可用性

　セキュリティと可用性は全く異なるものなので，区別して扱わなければならない。この見解に対し，「人命に影響するシステムへのサービス妨害攻撃（DoS）は明らかに大きなセキュリティ問題を引き起こす」，とすぐに反論する人が出る。確かにその指摘は正しいし，筆者も「セキュリティと可用性が相互作用しない完全に独立した要素」などと言っているわけではない。

　我々のセキュリティにかかわるシステムの可用性が重要な状況なら，両要素は密接に関係するし，可用性がセキュリティ問題になる。ところが，幸いなことに人間は相当な耐障害性を備えた生物であり，全面的な可用性は不要だ。

　このような例はどうだろうか。このブログ記事を書くためのテキスト・エディタがNullポインタ・アクセスを起こしてクラッシュしたら，記事を読んでもらえなくなるかもしれない。筆者は自分の記事が人々に興味を持たれたり，何かの役に立ったりすればよいと願っているが，記事が読めなくて迷惑を被る人はいないはずだ。「がんの治療に関する文章を書いたが，保存する前に消えてしまった」という例を持ち出してセキュリティ問題であると主張する人もいるだろう。いくらなんでも，それは拡大解釈し過ぎだ。どちらかというと，筆者の作業の進め方がまずくてセキュリティ問題を招いている。

　ただし，使っているソフトウエアがよく分からないタイミングで1時間に何度もクラッシュするとしたら，非常に迷惑な話である。だからこそ，筆者はクラッシュの原因となるバグを直そうという努力に感謝する。もちろん感謝はするが，ここで別の比較要素が登場する。

優先順位と価値

　情報を理解して対応するのに必要なリソースや時間は限られ，能力には限界がある。そのため，優先順位を決めなければならない。

　エディタがバージョンアップされ，文章を一つ書き終えるたびにファイルを保存するという手間を軽くできるなら，新バージョンのリリース情報を知りたい。ただし，今すぐ知る必要があるというほど急いではいない。新バージョンに移行しないからといって，攻撃を受けるわけではないからだ。

　一方，セキュリティが問題になっている状況だと攻撃される恐れがあるので，攻撃リスクを最小限に抑える新バージョンの早急な情報入手が必要となる。これこそセキュリティ・アドバイザリを出す理由であり，一般的なバグと異なる方法で情報を開示する理由である。

　可用性が必ずしもセキュリティと関係しないのと同様，優先順位が価値に結びつくとは限らない。セキュリティ関連の修正内容を詳しく公表しないことにすると，対応作業の優先順位をそれぞれの環境に合わせて決める際に必要な情報がユーザーに届かなくなる。

　修正履歴をすぐにダウンロードし，修正項目の一つ一つがセキュリティ・リスクにつながるかどうかを確認できる時間があるなら，修正内容を詳しく公表しないことも全く問題のないやり方だ。しかし，現実的には難しい。時間のない我々は，このような努力に感謝している。

---

Copyrights (C) 2008 Symantec Corporation. All rights reserved.
本記事の内容は執筆時点のものであり，含まれている情報やリンクの正確性，完全性，妥当性について保証するものではありません。
◆この記事は，シマンテックの許可を得て，米国のセキュリティ・ラボの研究員が執筆するブログSecurity Response Weblogの記事を抜粋して日本語化したものです。オリジナルの記事は，「Security Bugs Vs. Regular Bugs」でお読みいただけます。