Insider's Eye Windowsソース・コード流出がもたらす波紋 ――　ソース・コードから脆弱性を分析できる可能性　―― Michael Cherry 2004/04/28 Copyright(C) 2004, Redmond Communications Inc. and Mediaselect Inc.

本記事は、（株）メディアセレクトが発行する月刊誌『Directions on Microsoft日本語版』2004年5月15日号 p.28の「Windowsソース・コード流出の影響度　プログラマが残したコード・コメントが問題に？」を、許可を得て転載したものです。同誌に関する詳しい情報は、本記事の最後に掲載しています。

　2004年2月、Windowsソース・コードの一部がインターネットに流出した。Microsoftの顧客は、これによって生じるかもしれない新たなセキュリティの脆弱性に対処しなければならず、また開発者はこのソース・コードを見てみたいという誘惑と戦わなければならない。一方で、Microsoftとそのパートナー各社にとっては、さらに長期的な影響が及ぶことになるだろう。Microsoftは企業機密と知的財産を保護するための行動に出る構えだ。

　インターネットに違法に掲載されたソース・コードは、Windows NT 4.0とWindows 2000の一部のコンポーネント向け（Internet Explorer 5.0など）のもので、Windowsの完全なソース・コードのごく一部にすぎないとされている。Microsoftは「流出したソース・コードは、実行可能なWindowsのバージョンを構築するには不十分だ」としている。

　Microsoftは今回のソース・コード流出に関して、同社のネットワークやセキュリティの欠陥を突かれた結果ではない旨を直ちに発表し、責任の所在を突き止めるべく、現在、米連邦捜査局（FBI）の捜査に協力中であることを明らかにした。流出したコードに含まれる一部の情報は、Microsoftと長年のパートナー関係にあるMainsoft社がコードの出所である可能性を示している。Mainsoft社は1994年から、このソース・コードのライセンスを受けている。

Microsoftに問われる姿勢

　Windowsソース・コードがインターネットに流出したことは、Microsoftに大きな影響を及ぼす。同社は自社の知的財産（IP：Intellectual Property）を保護するための行動を起こし、ソース・コード流出の結果として生じるセキュリティの脆弱性の問題に対処し、また、ソース・コード流出に伴うイメージダウンを払拭しなければならない。今回のソース・コード流出はShared Sourceプログラムとは無関係と思われるため、Microsoftはこのプログラムはこれまでどおり続けることになるだろう。

知的財産（IP）保護の責任問題

　Microsoftのソース・コードは、企業秘密として保護され、さらに著作権と特許権によって守られている。IPをめぐる法律は難解で複雑だが、Microsoftには、自社のIPの保護に常に留意してきたという事実を示す義務がある。さもなければ、こうした保護の一部を失うことになりかねない。そのため、同社は現在、コード流出の経緯の調査でFBIに協力している。

　さらにMicrosoftは、このソース・コードをすでにダウンロードした人物、あるいはそうするつもりの人物に対して、そうした行為は違法であると警告している。同社は流出したソース・コードをダウンロードしたユーザーに対して、手元にあるコピーをすべて破棄し、どこで入手したかをMicrosoftに知らせるように呼び掛けている。

新たな脆弱性への対処

　インターネットにソース・コードが掲載されてほどなく、そのコードから、Internet Explorer（IE）5.0の新たな脆弱性が指摘され、その脆弱性を利用した攻撃手法が出回り始めた。Microsoftによれば、同社は2000年1月にTrustworthy Computing（信頼できるコンピューティング）構想の一環としてWindowsの開発を一時的に中断した際にこの脆弱性を突き止め、すでにIE 6.0 Service Pack 1ではこの脆弱性を解消しているという。同社はIEの古いバージョンを使っている顧客に対して、最新バージョンとサービスパックにアップグレードするよう呼び掛けている。

　ただしその一方で、Microsoftに対する疑問の声も上がっている。「多くの顧客がまだ古いバージョンを使っているにもかかわらず、なぜ最新版のIEしか修正しなかったのか？」「Windowsコードのレビューの一環として見つかったそのほかの脆弱性についても、Windows Server 2003とWindows XPでしか修正されなかったのか？」といった疑問だ。

　今回のソース・コード流出をめぐっては、新たな脆弱性が見つかる危険性が誇張されている傾向があるかもしれない。実際、プログラマはソース・コードを見ずに多くの脆弱性を発見している。たとえソース・コードを見られたとしても、それを読み、その内容を理解するのは、熟練のプログラマにとってですら難しいことだ（別掲のコラム「ソース・コードから脆弱性の分析は可能か？」を参照）。

ASN.1脆弱性詳細

　例えば、セキュリティ・ベンダのeEye Digital Security社はソース・コードにはアクセスできないにもかかわらず、Windowsの多数の脆弱性を発見している。一番最近では、eEye Digital Security社は自社

のセキュリティ強化製品を設計・開発している際に、MicrosoftのASN.1データ交換ライブラリの脆弱性を発見している。

コード・コメントから露見する開発者の姿勢

　今回のコード流出は、Microsoft自身のセキュリティの不備が原因だったわけではないため、同社の顧客にとっては、さほど深刻な懸念をもたらす問題ではないが、一方のMicrosoftにとっては、ソース・コードが詳細な吟味にさらされるというのは決まりの悪い経験となるはずだ。ソース・コードには、プログラマのコメントが含まれるが（プログラミングにおいては、コメントの追加は一般的かつ推奨すらされている慣行だ）、その多くには、Microsoftの社内、社外を問わず、ほかのプログラマに対する悪態や、失礼で侮蔑的な発言が数多く含まれている（こうしたコメントは通常、難解なコードに関する感情や、ほかのアプリケーションの欠陥を償うための回避策に関する感情を発散する手段となっている）。

　Shared Sourceプログラムの下で公開されているコードからはこうした扇動的なコメントは削除されているが、今回流出したコードにはオリジナルのコメントが数多く含まれていた。そうしたコメントに含まれる暴言のせいで、「Microsoftは競合製品よりも高い性能と高い信頼性を持たせるために、自社製品に特別なコードや回避策をWindowsに挿入した」といった批判につながらないとも限らない。少なくとも、こうしたコメントのせいで、同社のプログラマたちがプロらしからぬ集団と見られてしまうのは避けられないだろう。また開発者の中には、流出したコードを見て、そのコーディングの慣行やアルゴリズムから、Microsoftのコードと社内開発者のレベルに関して何かしらの結論を下す向きもあるかもしれない。

Shared Sourceプログラムへの影響を避ける

　MicrosoftはShared Source Initiativeを通じて、自社のソース・コードの公開に取り組んでいる。政府機関や大手企業顧客、大学、一部の個人ユーザーは同社のソース・コードにアクセスして、Windowsの動作をよりよく理解し、Windowsで動作するアプリケーションのデバッグに役立て、脆弱性の発見に利用できる。Shared Sourceライセンスでは、ライセンシーによるコードの使用条件が厳密に定義されているため、今回の流出はShared Sourceのライセンシーによるものとは思えない。

　Shared Sourceプログラムは、「コードを多くの目で吟味した方が、プログラムのセキュリティと信頼性を高められるはずだ」とするオープンソース・ソフトウェア擁護派への対抗手段の1つであるため、今回のコード流出にもかかわらず、Microsoftはこのプログラムから手を引くことはないだろう。

顧客と開発者への潜在的な影響

　今回のソース・コード流出により、最も直接的な影響を受けているのはMicrosoftだが、影響は同社の顧客やパートナー企業、開発者にも及んでいる。

■顧客とパートナー側の対策責任
　流出コードから見つかった脆弱性の攻撃手法がすでに出回っているため、顧客は自身のセキュリティ対策をレビューし、ファイアウォールが正しく設定されているかを確認し、アンチウィルス・ソフトウェアの最新の署名ファイルを保守し、既知の脆弱性については自社のソフトウェアに対してパッチを適用しておく必要がある。またShared Sourceライセンスでコードをライセンスしている顧客やパートナー企業には、自社のセキュリティ対策をレビューし、自らが今後の流出の原因となることのないよう確認する責任もある。

■開発者が似たコードを書いた場合
　今回のコード流出を受けて、開発者の間では、「よその企業のソース・コード、とりわけ今後自分が書くことになるかもしれないようなプログラムやルーティンのソース・コードを見てよいものかどうか」という問題をめぐり、活発な議論がわき起こっている。もしWindowsのソース・コードを見た開発者がその後、Windowsコードにどこかしら似たコードを書いた場合、その開発者はMicrosoftのIPを侵害したという批判にさらされかねない。上述のとおり、IPに関する法律は複雑なため、さまざまな解釈の余地があるが、そうした批判を防ぎたいのであれば、問題となっているコードには一切アクセスしていないという事実を開発者自身が断言できるに越したことはないはずだ。

関連リンク

• 今回のソース・コード流出に関する公式声明［英文］（米Microsoft）
  日本語抄訳（マイクロソフト）

• Mainsoft社のソース・コード流出に関する公式声明［英文］（Mainsoft）

• Shared Sourceライセンシング・プログラムの詳細［英文］(米Microsoft)
  日本語訳（マイクロソフト）

• eEye Digital SecurityがMicrosoft製品で見つけた脆弱性、および同社のWindows向けセキュリティ製品［英文］

• 別掲の「ソース・コードから脆弱性の分析は可能か？」で引用したコードは、Microsoft Developer Networkの記事「Fix Those Buffer Overruns!」から入手したもの［英文］（米Microsoft）
  

ソース・コードから脆弱性の分析は可能か？ 　今回のWindowsソース・コードの流出を受けて、大きな疑問となっているのは、「コードが一般の目にさらされたことが、果たしてセキュリティの脆弱性の増大につながるかどうか」という点だ。ソース・コードを読み解くのは難しい。開発者がコメントを含めたり、説明的な名前で変数を定義したりしてもだ。専門的な開発チームが記述したコードの場合、エラーが目立たない分、脆弱性を突き止めるのはますます難しいはずだ。 　実際、Microsoftの開発者ですら、Trustworthy Computing構想の一環としてWindows Server 2003のソース・コードを数カ月がかりで検証した際に、すべての脆弱性を見つけることはできなかった。その一方で、例えばeEye Digital Security社の開発者は最近、ソース・コードにアクセスできないにもかかわらず、WindowsのASN.1ライブラリに関する脆弱性を発見している。 　以下のコードは、開発者向けに提供されている一連の記事の一環としてMicrosoft Developer Network（MSDN）サイトに掲載されたものだ。執筆者のMichael Howard氏はこのコードを掲載し、読者に対して、脆弱性を見つけられるかどうかを尋ねている。この例からも、ほかの開発者が作成したコードの分析がいかに難しいかが分かるだろう。 WCHAR g_wszComputerName[INTERNET_MAX_HOST_NAME_LENGTH + 1]; // Get the server name and convert it to the Unicode string. BOOL GetServerName (EXTENSION_CONTROL_BLOCK *pECB) {     DWORD dwSize = sizeof(g_wszComputerName);     char szComputerName[INTERNET_MAX_HOST_NAME_LENGTH + 1];     if (pECB->GetServerVariable (pECB->ConnID,         "SERVER_NAME",         szComputerName,         &dwSize)) { // rest of code snipped 　このコードの問題は、変数のg_wszComputerNameとszComputerNameは一見どちらも同じデータを保持するように見えるが、1つ目の変数は16ビットのUnicode文字列であるため、長さは標準文字列である2つ目の変数の2倍になるという点だ。見過ごしがちな問題ではあるが、この2つの変数を入れ替えればバッファ・オーバーフローを引き起こせることになる。

Directions on Microsoft日本語版 本記事は、（株）メディアセレクトが発行するマイクロソフト技術戦略情報誌「Directions on Microsoft日本語版」から、同社の許可を得て内容を転載したものです。『Directions on Microsoft 日本語版』は、同社のWebサイトより定期購読の申し込みができます。

　

「Insider's Eye」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）