セキュリティを実践している人間によって、オープンソースがセキュリティに 与える影響について、数多くの議論がなされてきました。 主な論点の 1 つに、オープンソースはソースコードを公開しているので、誰でも つまり攻撃側と防御側のどちらもがソースコードを調べられるというものがあり ます。 この状況が決定的な影響力を持つことに、理性的な人びとは同意していません。
ここで、このトピックについて調査してきた方々を何人か紹介します。
Bruce Schneier 氏は、「賢明な技術者なら、セキュリティに関連した事項は
すべてオープンソースのコードに求めた方が良い」[Schneier 1999]としています。
またオープンソースなソフトウェアを安全にするに必須の条件をいくつかを論じて
います。
Advanced Encryption Standard (AES)の暗号化アルゴリズムを勝ち取った開発者
である Vincent Rijmen 氏は、セキュリティ上の脆弱性を簡単に見つけ出し、それを
修正するのには Linux のオープンソースの特性がこの上ない手段であると考えて
います。「より多くの人々が見るということ以上に重要なのは、このモデルにおいて、
より明快なコードを書くこと、標準を厳守することをみんなに強制している点です。
これはセキュリティ・レビューをスムーズに繰り返し行うことに他なりません」
[Rijmen 2000] としています。
Elias Levy (Aleph1) 氏は彼の論文である
"Is Open Source
Really More Secure than Closed?" でオープンソースのソフトウェアを
安全にする上での問題点を論じています。
要約してみると下記のようになります。
つまり、セキュリティ上の脆弱性が生じた時に、オープンソースとそうでないソフト
ウェアは大差がないのでしょうか。それは違います。オープンソースのソフトウェア
はそうでないソフトウェアよりも、もっと安全になる見込みが確かにあります。
しかし勘違いしないで欲しいのは、単にオープンソースだからといってセキュリティ
が保証されるわけでは無いということです。 オープンソースのソフトウェア・プロジェクトは、そうでないプロジェクトのソフト
ウェアよりも安全になる力を秘めています。しかしオープンソースのプログラムが
安全になるよりどころである、ソースコードが利用できること、たくさんのユーザが
セキュリティホールを見つけてそれを修正できるという事実は、人をだまして安心
させることにもなり得ます。 「私たちは、この議論からさらに 4 つの結論を引き出せます。第一に、ソース
コードにアクセスできれば、ユーザがシステムのセキュリティを改善できるように
なります。そのような才能と人材があるならばですが。第二に、限られたテストでは
一部のケースしか指摘できませんが、オープンソースのライフサイクルをもって
すれば、悪意の無い欠点に対して、より脆弱さが少ないシステムを構築できます。
第三に、3 つのオペレーティングシステムを数年間調査したところ、12 か月に
渡ってパッチが無い状態で既知の脆弱性をさらした日数が、2 つの商用システム
よりも、残り 1 つのオープンシステムの方が短かかった、という結果になりました。
最後になりますが、行き詰まっているのはオープンではない商用システムの開発
モデルの方です。システムとは手間をかけて維持、サポートして行くことでより安全
になるということ、手間をかけないシステムは安全ではないが利益は上がる、という
相反する問題であるからです。結論は出ているには出ていますが、この大切な点の
議論はまだ中途半端で、消費者に提供されるセキュリティを反映できる基準が切に
望まれています」
John Viega 氏の論文である "The Myth of Open Source Security" はこの点を論じています。要約してみると下記の
ようになります。
Michael H. Warfield's "Musings on open source security" はさらに
確信を持って、オープンソースがセキュリティに対して影響力を持つことを主張して
います。
Fred Schneider 氏はオープンソースはセキュリティに役に立つとは考えておらず、
「多くの目が(オープンな)ソースに注がれることで、システムのセキュリティを危うく
してしまうバグを発見できると信ずるに足る理由はありません」とし、また
「コードに含まれているバグが、攻撃手法として抜きんでているわけではありません」
[Schneider 2000]とも主張しています。
またオープンソースは、プログラム構築工程の管理を考慮していない、とも主張
していますが、実際には管理は存在しています。オープンソースのメジャーな
プログラムすべては、「責任者」の面目にかけて作成した公式バージョンがいくつか
存在します。
Peter G. Neumann 氏は「オープン・ボックス」ソフトウェア(ソースコードがある
状況下でのみで恐らく利用可能)を論じていて、その中で「オープン・ボックスである
ソフトウェアはシステムのセキュリティを本当に改善するのだろうか？ 自然と
そうなるわけではない。ただ可能性は無視できない」[Neumann 2000]としています。
TruSecure Corporation という Red Hat(オープンソースで企業活動している)が資金
提供をしている企業は、オープンソースがなぜセキュリティに有効であると思われて
いるのかを書籍にまとめました[TruSecure 2001]。
Natalie Walker Whitlock's IBM DeveloperWorks article
では賛否両論を載せています。
【訳註：Natalie Walker Whitlock's IBM DeveloperWorks article の日本語訳は、
http://www-6.ibm.com/jp/developerworks/linux/010615/j_l-oss.html
にあります】。
Brian Witten 氏と Carl Landwehr 氏、Micahel Caloyannides 氏 [Witten 2001]
は IEEE のソフトウェア関連論文でソースコードが利用できると、システムの
セキュリティに好都合に物事が運ぶはず、と控えめに結論づけています。
彼らによると、
注意して欲しいのは、時として脆弱性には、その存在を知られていないゆえにやられ ない場合があることです。つまりそのようなシステムは「実質的には安全」なのです。 理屈上これは真実ですが、問題は誰かがその脆弱性を見つけ出したなら、脆弱性の 修正に貢献せずに悪用するかもしれないという点にあります。 脆弱性が知られていないとしても、実際にその脆弱性がどこかに行ってしまうわけ ではありません。ただ、その脆弱性が時限爆弾のようにいつ悪用されるか知りようが ないだけです。 発見した脆弱性を誰かが悪用するという問題は、システムがオープンソースであろうが なかろうが本来関係ありません。 ソースコードの無いシステムは、より安全であるという主張がなされてきました。 攻撃側にとって情報が少ないため、脆弱性を見つけにくい、というのがその理由 です。 それに相対するものとして、攻撃側はほとんどソースコードを必要としておらず、 ソースコードを利用したいと思う時には逆アセンブルしてソースコードを再生成 してしまう、という意見があります。 Flake [2001]では、オープンでないコードに対してセキュリティ上の脆弱性をどの ように調べているかを論じています(たとえば、逆アセンブラを使って)。 かたや防御側は、ソースコードが無ければ問題を探しようがありません。 防御側はソースコードが無いと、攻撃側と比べて不利な立場になります。
脆弱性に対しての警告を発したり、脆弱性について議論したりしない方が良い、
という主張がなされる時もあります。
この説は理屈上はもっともらしいのですが、問題は攻撃側が既にありとあらゆる
経路を通じて、脆弱性についての情報を流してしまっているという点です。
つまり、そのようなアプローチでは防御側が脆弱なままで、攻撃側をまったく抑え
込めません。
これまで企業は、脆弱性があからさまになるのを必死に隠し通そうとしてきました。
しかし実績を見てみると、おおかたの企業はユーザに広く知れ渡るまで脆弱性を
修正しませんでした(脆弱性を修正したと主張できたのにもかからわず)。
これは「全面開示」が必要であることの論拠になっています。
Gartner グループは CNET.com での記事「Commentary: Hype is the real issue
- Tech News」で率直にコメントしています。
Microsoft の security response center のマネージャである Scott Culp
氏は、情報について長年言い争われていることに対し、オウムのようにお決まり
の文句を並べています。情報の配布についての道義的な議論は何度も繰り返され、
既にお馴染みになっています。たとえば、数世紀前に教会はコペルニクスと
ガリレオの天動説を弾圧しようしましたが...。
Culp 氏は Microsoft の製品で最近続発している脆弱性について「情報セキュリ
ティの専門家」を非難しようとしていますが、これは単に不誠実なだけです。
製品を製造した企業への批判を反らそうとする試みを象徴しているとも言え
ますが...。
関係者すべてが本当に努力すべきことは、改善のプロセスを途切れなく行うこと
です。より広範に脆弱性が知られれば、より速やかに修正ができます。
オープンソースのプログラムは、単独の企業が管理を強制していないため、誰かが トロイの木馬や悪意あるコードを潜り込ませることができる、という主張が時として なされます。 確かにトロイの木馬はオープンソースのコードに入れ込むことは可能です。 しかし同じように商用のコードにも潜り込ませられます。 従業員の中で、不満を抱えていたり、競争相手から賄賂を受けていたりしている者 が、悪意あるコードを潜り込ませるかもしれません。また組織の多くでは、オープン ソースであるプログラムのように、問題を発見できそうにありません。 なにしろ組織外の人間は、誰もソースコードをレビューできないわけですし、 社内でコードをレビューしている企業は、ごく少数に過ぎないからです (レビューを行っていたとしても、レビューしたコードが実際に使用されるという 保証は、ほとんどありません)。 オープンソースで無い企業を後で訴えられる、という考えもほとんど根拠がない ことに注意してください。ライセンスのほとんどすべては、押し並べて保証という ものを放棄しており、裁判所は普通、ソフトウェア開発会社に責任を負わせません。
Borland の InterBase サーバの件は、この点で興味深いケースです。 1992 から 1994 年という長い間、Borland は故意に「バックドア」を「InterBase」 というデータベース・サーバにしかけていました。 このバックドアは、ローカル、リモート両ユーザがあらゆるデータベース・オブジェ クトの操作ができ、任意のプログラムをインストールできてしまい、場合によっては 「root」としてそのマシンを制御できてしまうというものでした。 この脆弱性は少なくとも 6 年もの間、製品に含まれたままでした。誰もこの製品を レビューできず、Borland はその脆弱性を取り除くつもりもありませんでした。 Borland は 2000 年 7 月にソースコードを公開しました。 「Firebird」プロジェクトがそのソースコードとともに立ち上がり、2000 年 12 月 に InterBase のこの重大なセキュリティ上の問題が露見しました。 2001 年 1 月に CERT はこのバックドアの存在を CERT advisory CA-2001-01 として公表しました。 あきれたことに、そのバックドアはプログラムの ASCII ダンプ(クラッカー がよく使う手)をちょっと眺めただけで発見できるようなものでした。 この問題はオープンソースの開発者がコードをレビューすることで発見され、 すみやかにパッチが当てられました。 パスワードを知られなければプログラムは安全なままで、ソースを公開する とプログラムが安全でなくなると主張されるかもしれません。 私はそれは無意味だと考えます。ASCII ダンプは平凡で良く知られた攻撃手段 の 1 つです。攻撃者すべてが脆弱性を突然公開する衝動に駆られるわけではあり ませんし、実際のところ、その脆弱性が何度にも渡って悪用されなかった、という 確かな証拠はありません。 はっきりしていることは、ソースが公開された後、ソースコードが何回もレビュー され、脆弱性が見つかって修正された、ということだけです。 この状況をまとめると、オリジナルのコードに脆弱性があり、オープンソース になるやいなや簡単にその脆弱性が発見され、最終的には修正されたということ です。
ソースコードをオープンにする利点は、攻撃を受けるソフトウェアが増えない ということではなく、脆弱性を走査し評価する機会が増えるということです。 脆弱性を走査し評価するには、設定済みのシステムで意図的に脆弱性を探し出します。 最近になって Network Computing evaluation は、最高の走査ツール(数ある脆弱性 の中でも最も悪質な脆弱性を発見した)は、オープンソースの走査ツールである Nessus としました[Forristal 2001]。
いったい結論は何なのでしょう。 個人的には、プログラムというものがまずオープンソースとして作られると、最初 はユーザにとって安全性が低くても(脆弱性があらわになっても)、時を経るに したがって(数年程度)、オープンでないプログラムよりもさらに安全になる可能性 があると考えています。 プログラムをただオープンソースにするだけでは、すぐには安全になりませんし、 オープンソースなプログラムにすることで、安全になる保証もありません。
まず実際にコードをレビューしなければいけません。 これは議論において重要な点の 1 つです。現実的にオープンソースなプロジェクトで あれば、コードはレビューされるのでしょうか。 レビューを受ける回数が少なくなる要因はいろいろとあります。 ニッチでほとんど利用されない製品(レビューアの存在が期待できない)や開発者 がほとんどいない場合、まれにしか使われないコンピュータ言語がそれにあたります。 開発者が一人で協力者がいないプログラムは、間違いなくこの手のレビューを受けら れません。 その一方でプログラムの中には、中心となる作者が存在しかつ、ちょくちょくコード を調べたり、他の人間が行ったレビュー(少なくとも貢献にはなっている)を提案したり するメンバーがたくさん関っている場合もあります。 一般的にレビューアがたくさんいればいるほど、誰かが欠点を見つけ出す可能性 がより高くなります。これは「たくさんの眼」理論の基本です。
オープンソースであること自体が、レビューを受ける見込みを著しく減らす要因 の 1 つになるわけではありません。 ベンダーの中には「開示されているソース(disclosed source)」(「ソースが存在する」 (source available)とも言う)プログラムをオープンソースだとポーズをとるところが あります。しかしそのプログラムの 所有者はあいかわらず広範囲に独占的な権利を有しているので、「無償で」所有者の ために働こうという意欲がある人はほとんどいないでしょう。 風変わりで変則的な権利形態をとる(MPL のような)オープンソースのライセンス でさえ、問題を抱えています。 結局は、自分の成果に対して別の誰かが権利を持っているのであれば、ボランティア で参加する可能性は低くなるということです(Bruce Perens 氏はこの点について、 「一体誰が好んでただ働きで雇われの身になるんだい？」と言っています)。 やる気が旺盛なレビューアは、プログラムも修正したがります。このやる気を削ぐ ようなライセンスでは、たくさんの「眼」を失うことになります。 Elias Levy 氏はオープンソースのセキュリティに関する彼の論文の中でこの点で 間違いを犯しています。彼が分析したソフトウェア(例えば TIS の Gauntlet)は 当時オープンソースではなかったのです。
第二に、コードを書いたり、少なくともレビューしたりする人の中に、安全なプログラムの 書き方を理解している必要があります。 できれば、この文書が役に立てばと願っています。 「たくさんの眼」があっても、何を見つけだすかを知らなければ、何にもなりません。 理解している人たちがいる限りは、みんながみんな安全なプログラムの書き方を知らなくても かまわない、という点に気をつけてください。
第三に、一度問題が見つかったなら、すみやかに修正してそれを配布しなければ いけません。 オープンソースのシステムでは、速やかに問題が修正される傾向にありますが、 スムーズに配布されるとは限りません。 たとえば、OpenBSD の開発者たちはセキュリティ上の欠陥をレビューするのに 長けています。しかし、確認した問題点をオリジナルの開発者にいつもフィード バックするとは限りません。 つまりあるシステムのあるバージョンを修正するのには都合が良いのですが、他の システムは直されないままになってしまいます。
つまり、オープンソース・ソフトウェアのセキュリティへの影響度合いは、 セキュリティ界でまだ広範囲に渡って議論している最中です。しかし、著名な専門家 の多くはより安全になる可能性が大であると考えています。