前回はWindows XPマシンにインストールされている多数の修正パッチ情報の効率的な検索方法を紹介するとともに，Sasserワームまん延の原因はバッファ・オーバーラン（BOR）であることを説明しました。今回は，各種のウイルス/ワーム発生の最大の原因となっているBOR対策について考えてみることにします。米MicrosoftはBOR発生を抑えるためにどのような対策を採っているのでしょう。

BORの説明は十分か？

　前回紹介したサンプル・プログラムをWindows XP SP1環境で実行すると，100を超える数の修正パッチ情報が返されました。その数の多さに目を丸くした方もいるでしょう。今回は必要な修正パッチ情報のみを表示するサンプル・プログラムを紹介しておきます。このサンプル・プログラムはこちらで紹介したサンプル・プログラムをほんの少し変更して完成させています。

図1●サンプル・プログラムの実行結果
図2●Sasserの発生原因がBORであることを説明したサイト
　今回のサンプル･プログラムは，こちらからダウンロードできるようになっていますから，お時間のあるときにダウンロードし，実行してみてください。筆者のWindows XP SP1環境では図1[拡大表示]のような情報が返されました。

　この画面情報は前回説明しましたので，今回は説明を省略します。前回説明した検索手順に従っていくつかの参照リンクをクリックしていくと，図2[拡大表示]のような英文画面情報に出会うはずです。英語の不得手な人は，辞書を片手に読解してみるとよいでしょう。

　この画面情報は，Sasserの発生原因がBORであることをはっきりと認めた上で，BORの意味を説明しています。一見すると，この情報開示には問題がないように見えますが，筆者は，これでは不十分，と考えています。その理由は簡単です。この情報は「現在のBOR問題はとりあえず解決できますが，将来のBOR発生については分かりません」と述べているように思えるからです。

　筆者の周辺には，規模の小さなソフトウエア・ハウスがあり，彼らはWindowsアプリケーションを開発し，それをパッケージにして必死に販売しようとしています。彼らは「Microsoft社内で行われているBOR対策に関する分かりやすい説明」を切望しています。彼らの潜在的な顧客は，「Windowsはセキュリティに弱いらしい」，「セキュリティ問題の最大の原因であるBOR対策の実体がなかなか見えてこない」といった不安を抱えているからです。

　パッケージを販売する側としては，Microsoft社のBOR対策を分かりやすく説明し，消費者不安を一刻も早く解消したいと考えるのはきわめて自然なことです。筆者はこの視点に立つと，ウイルス/ワームまん延の原因がBORであることを認め，BORの技術的な説明をするだけでは十分ではないと考えています。

　Microsoft社は現在どのようなBOR対策を採っているだろう。BOR問題は将来改善されるのだろうか。この種の不安を解消する説明がほしいものです。パッケージ・ソフトの買い控えは，ソフトウエア・ハウスの存続を危うくします。それでは次に，筆者が調べた範囲のMicrosoft社のBOR対策を紹介することにしましょう。

Microsoft社が取っているBOR対策

　 Sasserまん延の原因は，BORにあります。これははっきりしていることです。しかし，BORの発生原因は何でしょうか。Bill Gates氏やMichael Howard氏のこれまでの発言内容から，おそらく，次のような原因を挙げることができると思います。

原因1：有効なコンパイラ・スイッチを使っていない
原因2：担当開発者のプログラミング・スキルが低い
原因3：仮想マシンを採用していない
原因4：コード・レビューが不十分
原因5：開発チームの低いモラル

　もちろんこれ以外の原因も当然考えられますが，想定される主要な原因はこの5つといってよいでしょう。今回は，これら5つの原因のうちの，第2の原因のみを取り上げます。この原因はさらに次のように詳細化できると思います。

詳細原因1：C言語プログラマの未熟さ
詳細原因2：C++言語プログラマの未熟さ

　この2つの詳細原因を一見すると，「なるほど」と感心する人も結構いると思いますが，感心しているだけでは，BOR問題の発生原因を取り除くことになりません。また，C言語やC++言語でプログラミングしている場合，ちょっとした不注意でBOR問題が発生してしまいます。プログラミング上の不注意は，プログラミングの未熟さには基本的に関係ありません。どのような優秀な開発者でも不注意なミスを犯してしまうものです。

　それではすべてのプログラマに適応できる解決策とは何でしょうか。Microsoft社は，ライブラリの見直しを行っています。筆者は，この解決策はかなり有効ではないかと期待している一人です。どのようなプログラミング言語を採用するにしても，その言語の内蔵機能だけで目的のアプリケーション・プログラムを開発することなどできません。プログラミング作業では，必ず，ライブラリを使います。これは，Visual Basicを軽量化して完成させたVBScriptスクリプト言語でさえ当てはまることです。

　Michael Howard氏のこちらの記事を読むと，安全なライブラリを用意するだけではなく，一部のライブラリは標準化委員会に標準ドラフト仕様として提出しています。これは決して悪いことではない，と筆者は考えます。記事の中では，次のようなBOR発生コードも紹介されています。

#include <vector>
vector<int> v(10);
v[20] = 10;　　　　　　 // BOR発生

図3●C++標準仕様とC++コミュニティを重視することを説明したサイト
　このコードは，C++標準テンプレート・ライブラリ（STL）の使い方を誤ると，BOR問題が発生することを示しています。Microsoft社によるライブラリ見直し作業は，このように，STLを含んでいることになりますから，C++コミュニティ全体にとってもよいことだと思います。しかしその反面，Microsoft社の影響力は強大であることもあり，標準C++仕様などへの同社の過度の影響を懸念している人もいると思います。Microsoft社のVC++アーキテクトであるHerb Sutter氏は，この点に関して図3[拡大表示]のような情報を自分のWebサイトで公開しています。

　ご覧のように，Herb Sutter氏はC++標準仕様とC++コミュニティを重視する，と宣言しています。同氏のより詳しい発言内容を知りたい方は，こちらを参照してください。Sutter氏は，C++の設計者でありかつ標準化作業で中心的な役割を果たしたStroustrup氏の考え方を十分理解しているはず，と筆者は期待しています。ちなみにSutter氏は，Microsoft社のアーキテクトの一人であるとともに，C++標準化委員会の幹事（Secretary）としても幅広く活動しています。

今回のまとめ

  • Microsoft社内では言語ライブラリ・ベースのBOR対策が取られている
  • BOR対策では標準仕様が考慮されている

　今回は以上で終了です。次回またお会いいたしましょう。ごきげんよう！