前回は具体的なサンプル・プログラムを使って,マイクロソフト日本法人の修正パッチ情報の公開プロセスを調べてみました。今回は,修正パッチ情報そのものを,次のような2つの視点から検討してみます。

視点1:インストールされた修正ファイルは何を語っているのか?
視点2:修正ファイルとWindows統合の関係

インストールされる修正ファイルは何を語っているのか?

図1●Windows XP SP1環境でのサンプル・プログラムの実行結果
図2●適用された3つのファイル情報
 それではさっそく,視点1から検討しましょう。いつものようにこちらからサンプル・プログラムをダウンロードし,実行してみましょう。デフォルトでは,Windows XP SP1環境の情報が返されますから,Windows 2000やWindows 2003 Serverなどを使用している方は,第14回第17回を参考にしてソースコードを変更してください。今回のサンプル・プログラムを私のWindows XP SP1環境で実行すると,図1[拡大表示]のような情報が返されます。

 図1は前回紹介したものとほとんど同じですが,上から4行目に「OLE32.DLL更新回数=> 2」という情報が追加表示されています。この情報の意味は,後で説明します。画面を下方向にスクロールすると,次のような3種類のファイルが更新されていることがわかります。

File: 0
BuildDate: Tue Aug 26 05:11:47 2003
FileName: ole32.dll
Location: C:\WINDOWS\System32
Version: 5.1.2600.1263

File: 1
BuildDate: Tue Aug 26 05:11:46 2003
FileName: rpcrt4.dll
Location: C:\WINDOWS\System32
Version: 5.1.2600.1254

File: 2
BuildDate: Tue Aug 26 05:11:27 2003
FileName: rpcss.dll
Location: C:\WINDOWS\System32
Version: 5.1.2600.1263

 それではここで,ページの最下段にある「Click」欄をクリックし,マイクロソフトがこれらのファイルをどのように説明しているのかを確認してみましょう。図2[拡大表示]をご覧ください。この画面の日付欄には,「2003-08-26」というデータが入っています。これは,サンプル・プログラムの出力結果では,「BuildDate: Tue Aug 26 05:11:46 2003」と表現されています。つまり,日付欄の情報は,修正ファイルがビルドされた日付なのです。

図3●2つの日付の間に2週間ほどの隔たりがあることについての説明
図4●修正ファイルのアンインストール情報
 修正ファイルがビルドされた日付は分かりましたが,前回説明したように,サンプル・プログラムが返してくれる公開日付は,「InstalledDate: 9/10/2003」となっていますね。「BuildDate: Tue Aug 26 05:11:46 2003」と「InstalledDate: 9/10/2003」という2つの日付の間に2週間ほどの隔たりがあることに気づきませんか? マイクロソフトはこの2週間の間にいったい何をしていたのでしょう。マイクロソフトはこのあたりの事情を図3[拡大表示]のように説明しています。

 注意書きを一読してみると分かるように,「脆弱性の影響を受けるかどうかを評価するためのテストを実施」していたわけです。つまり,ビルドしたバイナリ・コードの評価テストに2週間かけていたわけです。しかし,どのようなテストを行っていたかについては詳述されていません。このため,例えば,修正ファイルをインストールした後で発生する問題については,私たちユーザー側で解決する必要があります。かなり厳しい現実です。問題が発生した場合,(最後の手段として)インストールしたファイルをアンインストールする必要がありますが,マイクロソフトは図4[拡大表示]のようなアンインストール・プログラムを公開しています。

 アンインストール・プログラムはあくまでもインストール・プログラムとペアで使用される性格のものですから,インストール・プログラム情報にも目を通しておきましょう。2つのプログラムの間には使用できるスイッチ類に違いがあります。これは私の希望ですが,インストール・プログラムにだけ存在する,次のスイッチをアンインストール・プログラムにも追加してほしいと思います。

/l : インストール済みの修正プログラムの一覧を表示します。

 アンインストール処理には直接関係ない機能であることは確かですが,あれば便利であることは間違いありません。

修正ファイルとWindows統合の関係

 続いて視点2について考えてみましょう。これに関して先日,日米欧の大手コンピュータ企業/通信会社で組織する業界団体である米Computer & Communications Industry Association(CCIA)関係者は,Windows統合に関して,次のような見解を発表しました。

「Microsoft社が,自社OSと無数のアプリケーションを統合していることが,コンピューティング・インフラの複雑さと脆弱性に拍車をかけている。」

 詳細については,こちらを参照していただくとして,この見解は「統合」を進めてきたマイクロソフト社にとってはかなり厳しい指摘ではないかと思います。KB824146というパッチIDを持つ修正プログラムをインストールすると,先ほど紹介したように,3つのファイルが更新されます。3つのファイルの1つに「ole32.dll」というファイルがありますが,実は,このファイルは「統合」に深い関係があります。

 「ole32.dll」のOLEは,Object Linking and Embeddingの略語で,難しい表現になってしまいますが,オブジェクト間の連携(統合)機能を提供しています。今回のサンプル・プログラムを実行すると,「OLE32.DLL更新回数=> 2」という情報が表示されてます。このデータは,Windows統合を支えていると考えられる「ole32.dll」ファイルが2回更新されていることを示しているのです。皆さんの環境では,この数値はどうなっていますか? ぜひ実行してみてください。

今回のサンプル・コードの拡張上のヒント

 今回のサンプル・コードはリスト1のようになっています。基本的には,これまでのコードをほんのちょっと拡張したにすぎません。お時間のあるときに,ぜひソースコードを検討してみてください。

 先ほどWindowsの統合について触れましたが,多くの人は,「WindowsとIEの統合」という言葉をどこかで見聞きしたことがあると思います。この統合の歴史などを知りたい場合には,ソースコード内の次のコードを変更してみてください。

strPatchFile = oReg.RegRead(strRegTarget & "\" & i & "\FileName")
If ucase(strPatchFile) = ucase("ole32.dll") Then
iIntegrationOLE = iIntegrationOLE + 1
End If

 ucase("ole32.dll")部分をucase("shdocvw.dll")などに変更し,まず実行します。その後,表示文字列も必要に応じて変更したほうがよいと思います。

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