私はマイクロソフトでの業務の一部として、OS のセキュリティ、お客様からのフィードバック、進展の評価指標およびこれら 3 つが交差する部分の分析に多くの時間を費やしてきました。私が発見した 1 つの事柄として、セキュリティの理論上の考えとお客様の実際のセキュリティ上の懸念には非常に大きなギャップが存在するということがあります。このコラムは、4 回シリーズの第 2 回目で、このシリーズで、私はこのようなお客様の懸念事項を考察し、Microsoft Windows ベースのオペレーティング システムまたは Linux ベースのオペレーティング システムのいずれかの使用に関して考えるべく、問題を提起します。
特定の脆弱性の発見が複数の製品、またはある製品の複数のバージョンに影響を及ぼすことはめずらしくはありません。振り返ってみるとその事実は明白ですが、もう少し掘り下げて、マイクロソフトおよび Linux/オープン ソース コミュニティが問題をどのように取り扱っているかを明らかにし、それがお客様にとっての実際にどのような意味をもつかを考察したいと思います。
ソフトウェアの脆弱性について学び始める人たちにとって、すぐに Mitre Common Vulnerabilities and Exposures (CVE) ID (こちら
(英語情報) をご覧下さい) とは使用されている標準の識別番号であることが分かるでしょう。CAN-2004-1234 を識別番号の例としましょう。これを Mitre で調べるには、識別番号の前に “http://cve.mitre.org/cgi-bin/cvename.cgi?name=” が付いたものがその URL となります。(例: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1234)![]()
例とした “1234” を見ると、Red Hat Security Advisory
(英語情報) への参照、BitKeeper
(英語情報) への参照、Bugzilla
(英語情報) Securityfocus
(英語情報) および ISS
(英語情報) へのポインタがあります。Securityfocus の参照ページは、2.4.26 以前のすべての Linux カーネルが影響を受けることを示しており、これらのカーネルのバージョンを含み、マイナスの影響を受ける Linux ディストリビューションの 100 バージョン以上が記載されています。
話を戻して、マイクロソフトを例にしてセキュリティ情報 MS04-018 を見てみましょう。このセキュリティ情報は、攻撃者が Outlook Express (OE) をクラッシュさせる可能性がある OE に影響を及ぼすヘッダーの検証の問題をお客様に通知しています。このセキュリティ情報では、現在サポートされている OE の 6 つのバージョンが、Windows 98 および Windows NT を含む Windows オペレーティング システムの様々なバージョンで実行されている場合、影響を受けることが説明されています。
まず、マイクロソフトが Windows XP で実行されている OE のバージョンのみに更新プログラムをリリースし、その後にそのほかのバージョン用の更新プログラムをリリースするとしたらどうなるでしょうか? これにより、そのほかのバージョンについてのセキュリティ上のリスクにどのような影響が及ぼされるでしょうか? 2 つの状況が考えられます。
| • | その問題が既に公に知られている場合、更新プログラムのリリースは脆弱性を強調し、より広範囲にわたる人たちにその脆弱性の存在を知らしめます。 |
| • | その問題がまだ公開されていない場合、更新プログラムのリリースにより、その脆弱性が公に知られるようになり、より広範囲にわたる人たちにその脆弱性の存在を知らしめます。 |
更新プログラムが利用可能となっていないバージョンを使用しているユーザーにとっては、両方の状況においてセキュリティ上のリスクが増大するでしょう。その理由は、ベンダーから依然として何の更新プログラムも受けとっていないお客様もいらっしゃるにもかかわらず、攻撃のためのセキュリティ ホールがより多くの潜在的な攻撃者に知らされるためです。このため、ある製品のすべてのバージョンのお客様にとってのセキュリティ上のリスクを最小限にするために、ベンダーは同時にすべてのバージョン用の更新プログラムをリリースするポリシーを持つ必要があるという結論が導かれます。
マイクロソフト セキュリティ レスポンス チームが非公開で、または公開された方法のいずれかでセキュリティ上の脆弱性を確認した場合、マイクロソフトは同時にすべての言語においてサポートされているすべてのバージョンを修正するというポリシーを持っています。このポリシーが実現可能なのは、マイクロソフトが影響を受けるすべてのバージョンに対して、サポートおよびメンテナンスを提供しているためです。マイクロソフトが報告された問題をどのように取り扱っているかに関するさらに深い考察については、昨年私が執筆したコラム (英語情報) に詳述されています。
同時にすべてのサポートされているバージョンを修正するというプロセスの主な問題点の 1 つは、1 つのバージョン用の更新プログラムで問題が確認された場合、すべての更新プログラムのリリースが延期されるということです。セキュリティの専門家として、私は、この犠牲はその製品の様々なバージョンのユーザーに対するセキュリティ上のリクスを低減させるというトレードオフの価値があると見ています。
オープン ソースのソフトウェアの強みでもあり、弱みでもある点として、誰もがその変形を作成し、そのサポートを開始できるという点があります。しかし、このコラムのトピックに関して、オープン ソースの開発モデルはセキュリティ上のリスクという観点から、オープン ソースの製品にさらに挑戦をもたらします。
さきほどの Linux の 100 以上のディストリビューションに影響を及ぼす “1234” の例を思い出してみましょう。同時にすべてのバージョンについて、単一の更新プログラムのリリースを調整することは可能でしょうか? 理論的には、もちろん可能です! しかし、実際には、少々難しいでしょう。この問題を解決するためのオープン ソースの課題は少なくとも 2 つあります。
| • | 複数の Linux ディストリビューション (例: Gentoo、Debian、Red Hat) のうちの 1 つのディストリビューションで最初に修正された問題 |
| • | コンポーネント (例: Mozilla、gcc) 開発チームにより確認され、修正された問題 |
複数のディストリビューションの問題
distrowatch
(英語情報) の Web サイトで次のように述べられています。
Linux ディストリビューションは宗派のようなものです。今までに、「そのディストリビューションは最善の選択ではないかもしれない」と、他人に提言しようとした経験がある人なら、私の言わんとすることが分かるでしょう。そのようなことを提言したことがないとしても、おそらくメーリングリストまたは公共のフォーラムの中のひとつで「ディストリビューションを主張しあう戦争」に出くわしたことがあるでしょう。でも、それはいいのです。我々は我々が愛することに関して、たとえそれが単なる大量のプログラミングコードであっても、情熱的であるべきです。後に続くものは、Linux ディストリビューションに関する事実と数字です。個人的な意見は様々でしょうが、事実に対して意義を唱えることは相当困難です…
その Web サイトは次のように続けています。
現在、データベースに登録されているLinux ディストリビューションは386、BSD ディストリビューションは9つあります。これらのディストリビューションの中の50 は公的に中止
(英語情報) となっているか、またはそのディストリビューションの Web サイト (または製品の情報) が消滅している、または活動しなくなっている(2 年以上も新しいバージョンがリリースされておらず、それらの Web サイトには進行中の作業を示すものが何もない)ものです。
再び、先ほどの 1234 を例に見てみましょう。
| • | 2004 年 4 月 9 日、Kirill Korotaev が linux-kernel メーリング リストにメッセージ |
| • | 2004 年 12 月 23 日、Red Hat は Security Advisory RHSA-2004:689 |
| • | ISS と Securityfocus の双方によると、12 月 23 日は CAN-2004-1234 の問題が linux-kernel 購読者以外の人たちに最初に公開された日でした。 |
| • | Avaya は Red Hat を製品のいくつかに使用しており、2005 年 1 月 12 日、アドバイザリ ASA-2005-006 |
| • | Fedora ディストリビューションについて、2005 年 2 月 24 日 Fedora Core は FLSA:2336 をリリースしました。これは Red Hat のセキュリティ アドバイザリの約 2 ヶ月後でした。 |
| • | 現時点でそのほかのディストリビューションからのアドバイザリを見つけることはできません。たとえば、SuSE Enterprise Linux 8 が影響を受けると記載されていても、Novell はいまだ CAN-2004-1234 に言及するセキュリティ アドバイザリをリリースしていません。 |
この例は、あるディストリビューションがセキュリティの修正の通知を行う場合、そのほかのディストリビューションは、それ自体の修正をリリースするまで、元のものよりも大きなセキュリティ上のリスクに直面する可能性があることを示しています。
これらの修正がリリースされておらず、また通知が行われていないディストリビューションのユーザーにとっての良い面は、これらのユーザーのベンダーがセキュリティ問題についての通知を行っていない、または修正をリリースしていなくても、カーネルの修正を直接入手し、適用できることです。サポート契約への影響があるかもしれませんが、これらのユーザーに選択権があることに違いはありません。
修正プログラムが適用されたコンポーネント
Linux のディストリビューションは、ある時点での多くのコンポーネントのスナップショットをとり、ディストリビューションの開発用ツールを使用してそれらをまとめ、1 つの OS バージョンとしてセットをリリースすることにより作成されます。この例として、Red Hat Enterprise Linux AS v2.1、SuSE Linux Enterprise 8 および Ubuntu 4.10 があります。2004 年 10 月 20 日、SuSE Linux Enterprise Server 9 (SLES9) の CAN-2004-0816 の脆弱性に対応した SUSE Security Announcement - kernel (SUSE-SA:2004:037)
(英語情報) を見てみましょう。このアドバイザリは以下のように述べています。
iptable のファイアウォールのログ記録の規則に整数アンダーフローの問題が存在し、特殊な加工がされたIPパケットを使用してリモートの攻撃者により、マシンがクラッシュさせられる可能性があります。この攻撃はファイアウォールが有効になっていている場合にのみ可能です。
この問題を報告してくださった Richard Hart 氏に感謝の意を表します。
この問題は 2.6.8 upstream Linux kernel で既に修正されており、この更新プログラムは修正プログラムのバックポートを含みます。
「バックポート」という用語の使用は、ディストリビューションについての新しいコンポーネントの問題を示しています。Securityfocus
(英語情報) の情報によると、2.6.8 以前の 2.6 バージョンを使用しているディストリビューションが影響を受けることが示されています。カーネル チームはこの問題を修正しましたが、修正を適用するためには、カーネルを 2.6.8 またはそれ以降にアップグレードする必要が出てきました。
問題は、いくつかのディストリビューションは 2.6.8 以前のカーネルのスナップショットをとっており、そのバージョンはお客様がサポートされているバージョンとして使用しているものであることです。SuSE SLES9 および MandrakeSoft の 2 つのバージョンはこのカテゴリに分類されます。このため、ベンダーはこの修正をバックポートし、SuSE が行ったように、それをお客様のためにサポートすると約束したカーネルのバージョン用の更新プログラムとしてリリースしなければなりません。複数のディストリビューションの問題は、MandrakeSoft ユーザーが 2005 年 1 月 25 日まで MDKSA-2005:022 の修正プログラムを入手できなかったという所にも見受けられます。
別の例として、Apache Web サイトで v1.3 に影響を及ぼした問題を見てみましょう。CAN-2004-0174
(英語情報) に記述されている問題です。CVEの最初のリファレンスは bugtraq に記載されている 2004 年 3 月 19日の Apache HTTP Server 2.0.49 リリースの announcement
(英語情報) です。この announcement で、2.0.49 は 2.0.48 に存在した CAN-2004-0174 の問題を修正すると記載されています。これに続き、様々なディストリビューションが Apache の各自のバージョンについて、次のようにお客様にセキュリティ アドバイザリを提供していることが示されています。
| • | 2004 年 3 月 30 日、Trustix |
| • | 2004 年 5 月 3 日、Apple |
| • | 2004 年 5 月 12 日、OpenPKG および Slackware |
| • | 2004 年 5 月 17 日、MandrakeSoft |
| • | 2004 年 5 月 26 日、Gentoo |
| • | 2004 年 7 月 23 日、Red Hat |
最後の例として、Debian セキュリティ警告 DSA-639
を挙げます。これは明示的に次の 10 の脆弱性を通知しています。
Andrew V. Samoilov は、Debian がステーブルリリースとして出荷した mc (Midnight Commander、ファイル閲覧管理ソフトウェア) の現行バージョンに、mcのアップストリーム開発者によりソースに適用されたいくつかのバグフィックスがバックポートされていないことに気づきました。
つまり、オープン ソース モデルを使用することで、各ベンダーは各々のコンポーネントのバージョンを調整でき、コンポーネント チームが行う以上のサポートをお客様にお約束できる可能性があっても、お客様のセキュリティ上のリスクに影響を及ぼすことになる実際のセキュリティのメンテナンスに関する問題を抱える事になるわけです。
ベンダーまたは製品を比較する場合、往々にしてその価値や利益は比較検査環境で過度に単純化されています。サポートおよびライフサイクルの契約とともに企業に製品を提供しているすべての者にとって、セキュリティ更新プログラムの提供は初歩的な要件です。しかし、基本を越えて、ベンダーのポリシーとタイムリーな方法で複数のバージョンをサポートできる能力の両方からもたらされるセキュリティ上のリスクは、実際にどのような意味をもつのでしょうか。
オープン ソース モデルをこの観点から考慮すると、複数のベンダーおよび複数のディストリビューションには依存関係があり、1 つのベンダーまたはディトリビューションの問題は、他のベンダー、ディストリビューションにも影響を与える問題であることが明らかです。そのため、セキュリティのリスク管理は実に難しい問題だと言えます。
このような相対的なセキュリティについてのディスカッションで、私は皆さま自身でこのトピックを検証し、皆さま自身の結論を導かれることをお勧めします。皆さまのためにいくつかの参考事例をご紹介し、ベンダーと話し合いを希望されるであろう問題をいくつか挙げましたが、皆さま自身でこのトピックを検証することで、さらにベンダーと話し合いたい項目は追加されることでしょう。
実際のセキュリティ問題に関するこのシリーズの次のコラムでは、運用環境について考えてみたいと思います。「数時間で利用可能となる修正」に関連する実際のセキュリティ上の考慮点のいくつかを探っていきましょう。
Best Regards,
Jeffrey R. Jones
Senior Director, Microsoft Security Business and Technology Unit
この記事は、マイクロソフト セキュリティ ニュースレターで配信しました。