オープンソース・ソフトウェアの セキュリティ確保に関する調査報告書

オープンソース・ソフトウェアの
セキュリティ確保に関する調査報告書
第Ⅰ部 総論
オープンソース・ソフトウェアのセキュリティ確保
情報処理振興事業協会
セキュリティセンター
第Ⅰ部 オープンソース・ソフトウェアのセキュリティ確保
目
1.
次
はじめに................................................................................................................................. 1
1.1. 背景 .................................................................................................................................... 1
1.2. 目的 .................................................................................................................................... 1
2.
オープンソース・ソフトウェアとは ..................................................................................... 3
2.1. オープンソース・ソフトウェアの定義.............................................................................. 3
3.
オープンソース・ソフトウェアのセキュリティ ................................................................... 5
3.1. セキュリティ問題の増大.................................................................................................... 5
3.1.1.
Bugtraq ................................................................................................................... 5
3.1.2.
CERT Advisories..................................................................................................... 6
3.1.3.
CVE ........................................................................................................................ 6
3.2. 脆弱性とインシデントの関係 ............................................................................................ 7
3.3. 脆弱性の種類...................................................................................................................... 8
3.4. オープンソース・ソフトウェアに対するセキュリティの議論........................................ 10
3.5. セキュリティ確保のゴール .............................................................................................. 11
4.
セキュリティ確保のためのフレームワーク ........................................................................ 13
4.1. セキュリティ・フレームワーク....................................................................................... 13
4.2. セキュリティ管理者......................................................................................................... 15
4.3. 評価認定制度との関わり.................................................................................................. 15
5.
ソースコード検査 ................................................................................................................ 16
5.1. ソースコード検査の困難さ .............................................................................................. 16
5.2. 効率的なソースコード検査技術....................................................................................... 17
5.2.1.
効率的なソースコード検査技術の分類 ................................................................ 17
5.2.2.
効率的なソースコード検査技術 ........................................................................... 17
5.3. 効率的なソースコード検査技術で検出される脆弱性 ...................................................... 19
5.4. 何を利用すればいいのか.................................................................................................. 20
5.5. 効率的なソースコード検査技術の課題............................................................................ 21
6.
脆弱性対応 ........................................................................................................................... 22
6.1. 脆弱性への対応の困難さ.................................................................................................. 22
Ⅰ- i
第Ⅰ部 オープンソース・ソフトウェアのセキュリティ確保
6.2. セキュアな実行コード生成・実行環境技術..................................................................... 23
6.2.1.
セキュアな実行コード生成・実行環境技術の分類 .............................................. 23
6.2.2.
セキュアな実行コード生成ツール・実行環境 ..................................................... 24
6.2.3.
セキュアな実行コード生成・実行環境技術でカバーされる脆弱性..................... 25
6.3. 何を利用すればいいのか.................................................................................................. 25
6.4. セキュアな実行コード生成・実行環境技術の課題.......................................................... 25
7.
運用管理............................................................................................................................... 27
7.1. オープンソース・ソフトウェア運用モデルの分類.......................................................... 27
7.2. オープンソース・ソフトウェアをセキュアに保つための運用方法 ................................ 28
7.2.1.
セキュリティ情報の収集 ...................................................................................... 29
7.2.2.
セキュリティ情報への対応 .................................................................................. 29
7.2.3.
インシデントへの対応.......................................................................................... 30
7.3. まとめ............................................................................................................................... 32
8.
まとめ .................................................................................................................................. 33
8.1. セキュアなオープンソース・ソフトウェアの利用環境の構築に向けて ......................... 34
Ⅰ- ii
第Ⅰ部 オープンソース・ソフトウェアのセキュリティ確保
図
目
次
図 1.BUGTRAQ の脆弱性件数の推移（[15]より転記） ................................................................... 5
図 2.CERT/CC に報告のあったインシデントと脆弱性の総数...................................................... 6
図 3.CVE へのエントリーの登録件数推移([9]より転記) ............................................................... 7
図 4.脆弱性のライフサイクルモデル（[10]より転記）................................................................. 7
図 5.2001 年の CVE 脆弱性リストの内訳（[11]より作成） ......................................................... 9
図 6.CERT アドバイザリにおけるバッファーオーバーフローの比率（[12]より転記） .............. 9
図 7.セキュリティ・フレームワーク .......................................................................................... 14
図 8.検査ツールによる脆弱性検出実験結果 ............................................................................... 20
図 9.アプリケーションの脆弱性検出結果 ................................................................................... 25
図 10. 自組織のみで情報の収集と対応をするケース................................................................. 27
図 11. 有償外部リソースから情報を収集して、自組織で対応するケース ................................ 28
図 12. 有償外部リソースに情報の収集と対応を依頼するケース............................................... 28
Ⅰ- iii
第Ⅰ部 オープンソース・ソフトウェアのセキュリティ確保
表
目
次
表 1.セキュリティ情報提供組織の分類....................................................................................... 29
表 2.オープンソース・ソフトウェアにおけるインシデント対応表 ........................................... 31
表 3.オープンソース・ソフトウェア運用モデルと作業項目対応のまとめ ................................ 32
Ⅰ- iv
第Ⅰ部 オープンソース・ソフトウェアのセキュリティ確保
1. はじめに
1.1. 背景
近年、オープンソース・ソフトウェアは、ビジネス利用において非常に注目を浴びてき
ている。各国政府においても、従来の商用ソフトウェア1ではなく、オープンソース・ソフ
トウェアを積極的に利用していくことが検討されている。こうしてオープンソース・ソフ
トウェアが脚光を浴びる背景には、オープンソース・ソフトウェアのソースコード開示な
どの特性が挙げられる。オープンソース・ソフトウェアの利点は、ソースコードが開示さ
れているという点であり、そのため、利用者側でソースコードを検証することが可能であ
り、ソフトウェアで問題となるバグへの対処も場合によっては、利用者自身で対応するこ
とが可能である。
しかしながらこうした議論は、なんらオープンソース・ソフトウェアのセキュリティを
保証するものではない。オープンソース・ソフトウェアは従来の商用ソフトウェアとは違
い、１つの企業ではなく、コミュニティと呼ばれるインターネット上の有機的な集団で開
発されるものが多く、ソフトウェアのセキュリティに対して保証主体が明確ではない。
ソフトウェアの安全性を確保するためには、開発者側でのセキュリティ確保が重要であ
るが、オープンソース・ソフトウェアの特性を考えると、開発者側で十分にセキュリティ
を確保することは困難だと考えられる。そのため利用者側でできる限り、オープンソース・
ソフトウェアのセキュリティを検討するための枠組みが重要であり、そうした枠組みを確
立することにより、オープンソース・ソフトウェアに対する利用者のセキュリティ意識を
高め、開発者・利用者の両者においてオープンソース・ソフトウェアのセキュリティを向
上していくための動きが高まることが必要である。
1.2. 目的
本報告書は、オープンソース・ソフトウェアの利用者が、オープンソース・ソフトウェ
アを自身でセキュアに利用していくための技術的、方策的手法について調査したものであ
る。本報告書のアプローチは、オープンソース・ソフトウェアのセキュリティ問題をソフ
トウェアに内在するリスクとして捉え、利用者側で積極的にこれらのリスクを把握・低減・
管理していくことを目的とするものである。オープンソース・ソフトウェアの問題点をソ
ースコード検査により把握し、追加的なセキュリティ強化機能により把握した問題点を保
護し、保護できない部分は運用にてカバーしていくというものである。本報告書では、こ
れらのアプローチに不可欠なセキュリティ技術としてどのようなものがあり、どの程度問
題点をカバーできるのかについて調査する。さらに運用としてセキュリティ確保のために
どのようなことをしなければならないのかについてまとめる。
1一般的に Proprietary Software は「独占的ソフトウェア」と呼ばれるが、本論文では、Proprietary Software を「商
用ソフトウェア」と呼ぶこととする。詳細な定義は[1]を参照のこと。
Ⅰ- 1
第Ⅰ部 オープンソース・ソフトウェアのセキュリティ確保
しかしながら、本報告書での利用者側からのセキュリティ確保のアプローチは、オープ
ンソース・ソフトウェアに内在する問題点のすべてに対応できるというものではないこと
に注意していただきたい。本来セキュリティは追加される機能ではなく、設計や実装にお
いて、十分に検討・確保されなければならない機能であり、従って性能や信頼性と同じよ
うに取り扱われるべきものだからである。そのためソフトウェア開発時に、開発者がソフ
トウェアにおけるセキュリティ問題を十分認識し、解決していくことが重要である。また
一方でオープンソース・ソフトウェアの開発側だけに、こうした要求を求めていくだけで
はなく、利用者側においてもセキュリティを評価し、作成者側にフィードバックしていく
ことが、重要である。作成者側・利用者側両者でオープンソース・ソフトウェアのセキュ
リティ確保のための試みを行うことにより、オープンソース・ソフトウェア全体のセキュ
リティ向上につながっていくことが望まれる。
Ⅰ- 2
第Ⅰ部 オープンソース・ソフトウェアのセキュリティ確保
2. オープンソース・ソフトウェアとは
2.1. オープンソース・ソフトウェアの定義
定義上、オープンソースとはソースコードが利用可能であることを意味している。オー
プンソース・ソフトウェアはソースコードを利用し、複製・修正して再配布することが可
能である。さらに配布されるソフトウェアは無料または有料にて提供される。仮にエンド
ユーザがソフトウェアに変更を加えたとしたら、それらの変更を個人的なものとして保持
しておくことも、将来的にその変更がソフトウェアに反映されるようにコミュニティに還
元することも選択可能である。正確なオープンソースのライセンスは、オープンソース・
イニシアティブ（OSI）によって定義されている。OSI は法人化されていない非営利の研究・
教育機関であり、オープンソースのトレードマーク定義・所有、およびオープンソース・
ソフトウェアの推進を押し進める役割を持つ団体である。OSI の定義によれば、以下の 9 つ
の項目が定義されている[2]。
1. 再頒布の自由
「オープンソース」であるライセンス(以下「ライセンス」と略)は、出自の様々なプロ
グラムを集めたソフトウェア頒布物(ディストリビューション)の一部として、ソフトウ
ェアを販売あるいは無料で頒布することを制限してはならない。 ライセンスは、この
ような販売に関して印税その他の報酬を要求してはならない。
2. ソースコード
「オープンソース」であるプログラムはソースコードを含んでいなければならず 、コ
ンパイル済形式と同様にソースコードでの頒布も許可されていなければならない。何
らかの事情でソースコードと共に頒布しない場合には、ソースコードを複製に要する
コストとして妥当な額程度の費用で入手できる方法を用意し、それをはっきりと公表
しなければならない。方法として好ましいのはインターネットを通じての無料ダウン
ロードである。ソースコードは、プログラマがプログラムを変更しやすい形態でなけ
ればならない。意図的にソースコードを分かりにくくすることは許されないし、プリ
プロセッサや変換プログラムの出力のような中間形式は認められない。
3. 派生ソフトウェア
ライセンスは、ソフトウェアの変更と派生ソフトウェアの作成、並びに派生ソフトウ
ェアを元のソフトウェアと同じライセンスの下で頒布することを許可しなければなら
ない。
Ⅰ- 3
第Ⅰ部 オープンソース・ソフトウェアのセキュリティ確保
4. 作者のソースコードの完全性
(integrity)
バイナリ構築の際にプログラムを変更するため、ソースコードと一緒に「パッチファ
イル」を頒布することを認める場合に限り、ライセンスによって変更されたソースコ
ードの頒布を制限することができる。ライセンスは、変更された ソースコードから構
築されたソフトウェアの頒布を明確に許可していなければならないが、派生ソフトウ
ェアに元のソフトウェアとは異なる名前やバージョン番号をつけるよう義務付けるこ
とは構わない。
5. 個人やグループに対する差別の禁止
ライセンスは特定の個人やグループを差別してはならない。
6. 利用する分野(fields of endeavor)に対する差別の禁止
ライセンスはある特定の分野でプログラムを使うことを制限してはならない。例えば、
プログラムの企業での使用や、遺伝子研究の分野での使用を制限してはならない。
7. ライセンスの分配 (distribution)
プログラムに付随する権利はそのプログラムが再頒布された者全てに等しく認められ
なければならず、彼らが何らかの追加的ライセンスに同意することを必要としてはな
らない。
8. 特定製品でのみ有効なライセンスの禁止
プログラムに付与された権利は、それがある特定のソフトウェア頒布物の一部である
ということに依存するものであってはならない。プログラムをその頒布物から取り出
したとしても、そのプログラム自身のライセンスの範囲内で使用あるいは頒布される
限り、プログラムが再頒布される全ての人々が、元のソフトウェア頒布物において与
えられていた権利と同等の権利を有することを保証しなければならない。
9. 他のソフトウェアを制限するライセンスの禁止
ライセンスはそのソフトウェアと共に頒布される他のソフトウェアに制限を設けては
ならない。例えば、ライセンスは同じ媒体で頒布される他のプログラムが全てオープ
ンソース・ソフトウェアであることを要求してはならない。
これらのライセンス条項のもとで頒布されるソフトウェアが、オープンソース・ソフト
ウェアである。実際には、オープンソース・ソフトウェアとして提供されているソフトウ
ェアは様々なライセンスのもとで提供されている。
Ⅰ- 4
第Ⅰ部 オープンソース・ソフトウェアのセキュリティ確保
3. オープンソース・ソフトウェアのセキュリティ
オープンソース・ソフトウェアのセキュリティについては、多くの議論が行われている[4]。
さらにオープンソース・ソフトウェアの利用が拡大していく中で、こうした議論が活発化
してきている。例えば、近年オープンソース・ソフトウェアの導入を積極的に議論してい
る各国政府機関での調査などにおいても、オープンソース・ソフトウェアのセキュリティ
は重要な項目として取り上げられており、セキュリティについて様々な議論がなされてい
る[5]。本章では、オープンソース・ソフトウェアのセキュリティに関連するいくつかの事例
を挙げながら、オープンソース・ソフトウェアのセキュリティについて見ていく。
3.1. セキュリティ問題の増大
ソフトウェアのセキュリティ問題について言及する多くのサイトがインターネット上に
は存在する。これらはセキュリティに関する問題を取りまとめ、一般に公開している。こ
れらの情報を参照すると、オープンソース・ソフトウェアを含めたソフトウェアのセキュ
リティが年々重要な問題となってきていることがうかがえる。ここでは以下の 3 つの例か
らセキュリティ問題の増加について見ていく。
3.1.1. Bugtraq
Securityforcus.com によって管理されている Bugtraq メーリングリストはセキュリティの問
題について取り上げた e-mail ベースのディスカッションの場を提供するものである[6]。多く
のソフトウェアの脆弱性は、はじめに Bugtraq に報告される。Bugtraq では情報公開の原則
がとられており、さまざまな情報がこの原則に基づいて、いち早く掲載される。Bugtraq に
はソフトウェアの脆弱性に関する情報が集められ、公開されており、その数は年々増大し
ている。以下は[3]によってまとめられた 1998 年から 2000 年の間の Bugtraq への脆弱性情報
の統計データである。Bugtraq に寄せられる脆弱性情報の件数が 2000 年は 1998 年の 4.6 倍、
1999 年の 1.3 倍と年々増大していることがうかがえる。
図1.
Bugtraq の脆弱性件数の推移（[15]より転記）
Ⅰ- 5
第Ⅰ部 オープンソース・ソフトウェアのセキュリティ確保
3.1.2. CERT Advisories
CERT コーディネーションセンター(CERT/CC)は米国カーネギーメロン大学によって運営
されている連邦政府設立の研究・開発センターである[7]。CERT/CC はインターネットのセ
キュリティ脆弱性について調査したり、攻撃によって被害を受けたサイトへのインシデン
トレスポンスサービスを提供したり、様々なセキュリティアラートの出版を行っている。
セキュリティコミュニティーの多くの人は、CERT/CC のアナウンスを最低限知るべき情報
として位置づけ、情報の参照を行っている。また CERT/CC は脆弱性発見時の届出機関であ
り、実際のインシデント発生時の届出機関でもあるので、それらの傾向を把握するための
情報収集に利用される。下図は CERT/CC で公表されているインシデントと脆弱性の統計を
グラフでまとめたものである。インシデント・脆弱性ともに、ここ数年において急激に総
数が増大していることがうかがえる。
Incidents
Vlunerabilities
80000
3500
70000
3000
60000
2500
50000
2000
40000
1500
30000
20000
1000
10000
500
0
1988 1990 1992 1994 1996 1998 2000 2002
図2.
0
1995
1997
1999
2001
CERT/CC に報告のあったインシデントと脆弱性の総数
3.1.3. CVE
CVE (Common vulnerabilities and Exposures)は脆弱性の統計データである[8]。脆弱性情報に
関する統一的な表記法を定義し、それにもとづいて、顕在化されている脆弱性の情報をリ
ストとしてまとめたものである。米国の調査機関である MITRE が実施するもので、2003 年
1 月時点で 2223 のエントリーが登録されている。下図は 1999 から 2002 年の間に CVE のリ
ストに登録された件数である[9]。表中の下段のデータが登録されたエントリー数である。こ
こ数年において多くの脆弱性情報が追加されていることがうかがえる。
Ⅰ- 6
第Ⅰ部 オープンソース・ソフトウェアのセキュリティ確保
図3.
CVE へのエントリーの登録件数推移([9]より転記)
これらの統計データはオープンソース・ソフトウェアに限った統計データではない点に
注意していただきたい。しかしながら、ソフトウェア全体としては発見される脆弱性の数
は増大しており、それとともに、インシデントの数も増大している。多少の差はあるが、
商用ソフトウェアであれ、オープンソース・ソフトウェアであれ、インシデント、脆弱性
ともに増加の状況にあると言える。
3.2. 脆弱性とインシデントの関係
インシデントと脆弱性との間には強い関係があることが示されている。[10]では脆弱性の
ライフサイクルモデルが定義されている。このモデルは脆弱性が検出されてから、広く公
開されるまでインシデントは徐々に増大し、パッチのリリース後緩やかにインシデントが
減少していくというものである。脆弱性が改善されたとしても、インシデントが収まるま
でには非常に長い期間を要する。1 つの脆弱性が長い時間に渡って多くのインシデントを発
生することがわかる。
図4.
脆弱性のライフサイクルモデル（[10]より転記）
Ⅰ- 7
第Ⅰ部 オープンソース・ソフトウェアのセキュリティ確保
このモデルでは、検出されるソフトウェアの脆弱性が、インシデントの増加に強く関わ
っていることがわかる。ソフトウェアの脆弱性を少なくしていくことは、インシデントの
発生を抑える強力な手段であり、セキュリティを高めていくための基本的で重要な手段で
あると考えられる。
3.3. 脆弱性の種類
では、どのようなソフトウェアの脆弱性から我々は身を守らなければならないのであろ
うか？ どのような脆弱性に対応していくことが要求されているのかという点について正
確に把握することはリスクの管理の上では非常に重要である。しかしながら脆弱性は多岐
にわたっており、その分類が非常に困難である。本報告書では、[11]で示されたソフトウェ
アの脆弱性の分類を示す。[11]では3.1.3で紹介した CVE に登録された脆弱性を分析し、以
下のように 8 つに分類している。
脆弱性
#
内容
プログラムのメモリー領域を溢れさせて、不正
なコードを実行させる攻撃
1
バッファーオーバーフロー攻撃
2
フォーマット・ストリング・バグ printf()関数などのフォーマット定義を悪用し
攻撃
て、不正なコードを実行させる攻撃
3
/tmp 等に不適切なアクセス権でファイルを作成
レースコンディション又はシンボ するアプリケーションなどを利用して、パスワ
リックリンク攻撃
ードファイルなど重要なファイルのアクセス権
を奪取する攻撃
4
ファイルパス名の悪用による攻撃
ファイルのパス名に不正なコードを入力して、
不正にファイル等にアクセスする攻撃
5
リソースリーク
リソースへのアクセス権が適切に設定できてい
ないために、リソース情報を不正に入手される
攻撃
6
プログラムの設定などによってファイル等のア
アクセス権の不適切な設定をつい
クセス権が不十分な部分をついて、不正に情報
た攻撃
を読み出す攻撃
7
不適切な入力による攻撃
不正な入力 CGI などを通じて、不正な入力を送
り込み、不正にコマンド等を実行する攻撃
8
その他
上記攻撃に分類できない攻撃
Ⅰ- 8
第Ⅰ部 オープンソース・ソフトウェアのセキュリティ確保
これらの脆弱の分類に従って、CVE の 2001 年に検出された脆弱性を分類したものが以下
の図である。
Others
Buffer overflows
16%
19%
Format bugs
Malformed input
6%
16%
Resource leaks
6%
Pathnames
Access
10%
16%
Symbolic links
11%
図5.
2001 年の CVE 脆弱性リストの内訳（[11]より作成）
また文献[12]によれば、CERT アドバイザリの 50％以上がバッファーオーバーフロー攻撃
に関するものであるという報告がされている。
左は CERT のアドバイザリの総数（左棒グラフ）とバッファーオーバーフローの
脆弱性の総数（右棒グラフ）。
右はバッファーオーバーフローの脆弱性の比率を示す。
図6.
CERT アドバイザリにおけるバッファーオーバーフローの比率（[12]より転記）
これらの脆弱性を低減していくことは、オープンソース・ソフトウェアのセキュリティ
を確保していくために重要である。ソフトウェアの脆弱性を把握・保護・改善していくた
めのスキームが提供されていることで、ソフトウェアのセキュリティを確保していくこと
が可能となる。ソフトウェアの脆弱性低減のための研究もこれらの脆弱性を対象に行われ
ている。特に危険度の高い脆弱性への対応が行われている。
Ⅰ- 9
第Ⅰ部 オープンソース・ソフトウェアのセキュリティ確保
3.4. オープンソース・ソフトウェアに対するセキュリティの議論
オープンソース・ソフトウェアは商用ソフトウェアに比べてセキュアかという議論は頻
繁に行われている。オープンソース・ソフトウェアはソースコードが開示されているため、
多くの人がコードに目を通しており、バグの発見が早いといった議論から、ソースコード
を開示していてもセキュリティの問題点を発見できるかは疑問であるといった様々な議論
がある。ここでは、こうしたオープンソース・ソフトウェアのセキュリティに関する異な
る複数の議論を取り上げ、比較する。
(1) 伽藍とバザール
Raymond はオープンソース・ソフトウェアには“Linus’s Law”2と呼ばれるソフトウェ
アのバグ発見時の利点があることを指摘している[13]。多くの開発者らによってソース
コードが眺められるために、バグの検出が早いというものである。”Linus’s Law”はバグ
に関して言及したもので、セキュリティの問題を取り上げたものではないが、オープ
ンソース・ソフトウェアのセキュリティの議論において、利点として引用されている。
さらに Raymond は、オープンソース・ソフトウェアにはソースコードを見る 3 つの経
済的な動機が提供されており、“Linus’s Law”が適切に機能していると指摘している。
(2) Look at the Security Benefits of Source Code Access
TrustSecure 社は 2001 年にオープンソース・ソフトウェアのセキュリティ上の利点を
説明したレポートを公開した[14]。このレポートでは Raymond の指摘する “Linus’s Law”
がセキュリティに効果的に働くことが主張されている。またオープンソース･ソフトウ
ェアには自分でバグを修正できるメリットや、ソースコードレベルでセキュリティを
強化するためのツールが利用できるといったメリットもあるという。
(3) Building Software Security
これに対して Viega は、オープンソース・ソフトウェアにおける”Linus’s Law ”が本当
に機能しているかどうかについて、
wu-ftpd 等の事例をあげて疑問を投げかけている[15]。
wu-ftpd は 1999 年から 2000 年にかけて 6 つのクリティカルな脆弱性が検出されている。
wu-ftpd は利用者が多かったにも関わらず、これらの脆弱性が発見されなかった。この
事例はバグを検出することは、非常に困難な作業であることを示している。そしてソ
フトウェアのセキュリティを確保していくためには、ソースコードを書く人間が、セ
キュリティに習熟していくべきであり、ソースコード検査や、脆弱性対応などの技術
を活用していくことが必要であると述べている。
2 Raymond は”Given enough eyeballs, all bugs are shallow”という表現で”Linus’s Law”を表している。
Ⅰ- 10
第Ⅰ部 オープンソース・ソフトウェアのセキュリティ確保
(4) Secure Programming for Linux and Unix HOWTO
Wheeler は[4]のなかで、オープンソース・ソフトウェアは商用のソフトウェアに比べ
て、初めはセキュアでないにしろ、実際に利用されていく過程で、商用ソフトウェア
以上にセキュアになると指摘している。しかし、オープンソース・ソフトウェアが突
然セキュアになることはないし、オープンソース・ソフトウェアのセキュリティを保
証することもできないとしている。Viega と同じように“Linus’s Law”が機能的に働いて
いるかは疑問であるとしている。
オープンソース・ソフトウェアのセキュリティの議論においては、現在、オープンソー
ス・ソフトウェアは一般のソフトウェアに比べてセキュアであるという見方が大多数を占
めている。オープンソース・ソフトウェア採用の動きを強めている政府機関においてもこ
うしたオープンソース・ソフトウェアのセキュリティの強さは、採用の大きな理由となっ
ている。しかしながら、Viega の議論にもあるように、ソースコードを見ることができても、
本当に安全とは言い切れないように思われる。彼の議論はそうした疑問を投げかけている。
Wheeler によれば、オープンソース・ソフトウェアは一般のソフトウェアよりもセキュリテ
ィが強いというものではなく、オープンソース・ソフトウェアの方が、セキュリティを高
めるための手段を利用者が講じることができる点を指摘している。オープンソース・ソフ
トウェアと商用ソフトウェアではどちらがセキュアかという議論だけではなく、よりソフ
トウェアのセキュリティを高めるためには、オープンソース・ソフトウェアのモデルを積
極的に利用していくべきである。オープンソース・ソフトウェアはソースコードにアクセ
スできることにより、そのセキュリティ能力を高めていくことができる。そのためにも、
オープンソース・ソフトウェアのセキュリティ確保の方策を、開発者・利用者ともに理解
していくことが重要である。
3.5. セキュリティ確保のゴール
オープンソース・ソフトウェアにとってセキュアとは何を意味しているのであろうか。
オープンソース・ソフトウェアはどのようにセキュアにすることができるのか。セキュリ
ティは多くの人が認識しているように固定的な特徴ではない。時間の変化によってセキュ
リティの概念も大きく変化する。セキュリティは信頼性の一部として捉える必要がある。
100％万全のセキュリティは基本的にはありえない。セキュリティは信頼性と同様に高めて
いくものである。オープンソース・ソフトウェアのセキュリティにおいても一般のソフト
ウェアと同様に 100％万全のセキュリティ確保はありえない。それに関しては、技術的な対
策と運用的な対策が不可欠である。3.1の脆弱性の議論は、オープンソース・ソフトウェア
であろうと、一般のソフトウェアであろうとセキュリティ上の危険性が潜んでいることを
示している。そこには多少の違いこそあれ、セキュリティ上のリスクを利用者は負わなけ
ればならない。利用者の立場から見た場合、オープンソース・ソフトウェアのセキュリテ
Ⅰ- 11
第Ⅰ部 オープンソース・ソフトウェアのセキュリティ確保
ィを確保するためには、単にオープンソース・ソフトウェアを提供しているコミュニティ
を信頼するだけでなく、自己（又は組織）でオープンソース・ソフトウェアのセキュリテ
ィを評価し、確保していくための手法を持つことが重要である。利用するオープンソース・
ソフトウェアのセキュリティを何らかの手段で測定して、技術的な手法でカバーできる範
囲はその手法を適用してオープンソース・ソフトウェアのセキュリティを強化し、そうで
ない部分に関しては、運用的な手法で、セキュリティを保持していくことが重要になる。
従来はこうした活動は、ベンダなどが担う部分でもあったが、オープンソース・ソフトウ
ェアの利用に際しては、特にこうした自主的な取り組みが重要となってくる。またこうし
た方法論を、オープンソース・ソフトウェアの利用に際して定義することで、これまで以
上にセキュリティの確保を図ることが可能である。こうした方法を用いて、そのための技
術的・運用的な方法を自己（組織内）に根付かせていくことが、オープンソース・ソフト
ウェアの利用におけるセキュリティ確保のゴールとなる。このゴールは決して利用面だけ
ではなく、オープンソース・ソフトウェア開発においても意味を持つものであると考える。
Ⅰ- 12
第Ⅰ部 オープンソース・ソフトウェアのセキュリティ確保
4. セキュリティ確保のためのフレームワーク
本章では、オープンソース・ソフトウェアのセキュリティを確保していくために、セキ
ュリティ確保のフレームワークを提案する。というのも、オープンソース・ソフトウェア
の利用に当たっては、その責任の所在が明確でないために、利用者側でセキュリティ上の
問題点を管理していく必要が強まるためである。オープンソース・ソフトウェアはそうし
た意味で、利用の柔軟さはあるものの、選択の幅が非常に広く、こうしたセキュリティの
確保においてユーザに実際の作業を要求する面がある。ここでは、前章で述べたように、
オープンソース・ソフトウェアの脆弱性を低減していくことがセキュリティ確保の上で重
要であることを前提に、脆弱性管理（セキュリティ確保）のためのフレームワークを定義
する。
4.1. セキュリティ・フレームワーク
オープンソース・ソフトウェアの利用におけるセキュリティの確保において最も重要な
ことは、オープンソース・ソフトウェアの問題点を自己の管理において把握し、対象のシ
ステムに応じて適切に問題点を把握し、低減の手段を講じていく事である。ここでいう問
題点とはオープンソース・ソフトウェアが抱える脆弱性を指す。オープンソース・ソフト
ウェアは商用ソフトウェアと比べてセキュリティが低いわけではないことは前述したとお
りである。しかしながら、オープンソース・ソフトウェアも商用ソフトウェアもソフトウ
ェアであることに変わりなく、数量的な違いはあれ、セキュリティ上の問題点が存在する。
商用ソフトウェアの場合は、問題点を利用者が把握する手段は少ない。それはソースコー
ドそのものが見えないため、リスクを把握することが困難であるからである。一方オープ
ンソース・ソフトウェアでは、ソースコードが公開されているために、様々な手段を利用
して、リスクをある程度把握し、さらにそれに応じた対応策を講じることが可能となる。
オープンソース・ソフトウェアの特徴である、ソースコード開示の特性は、こうしたセキ
ュリティの管理において非常に重要な意味を持つこととなる。
オープンソース・ソフトウェアの利用におけるセキュリティ確保を形式化するために、
以下のようなオープンソース・ソフトウェア利用の 3 ステップから成るセキュリティ・フ
レームワークを定義する。
第１段階：ソースコード検査
オープンソース・ソフトウェアでは商用ソフトウェアと違い、ソースコードを利用
することができる。そのため、利用者サイドでこのソースコードを利用して、ソフト
ウェアに含まれるバグや脆弱性のチェックを行うことができる。この結果に従い、脆
弱性の評価を行い、ソフトウェアのセキュリティ上の問題点を把握する。
Ⅰ- 13
第Ⅰ部 オープンソース・ソフトウェアのセキュリティ確保
第 2 段階： 脆弱性対応
ソースコードを検査し脆弱性を検出できたとしても、利用者側で検出された脆弱性
を修正することは困難である。把握された問題点に対して、ソースコードの修正無し
に、脆弱性を保護し、リスクを軽減するための技術的な方策が必要である。脆弱性を
自動的に検出、保護してくれる仕組みを導入することで、第一段階で認識した問題点
を低減し、オープンソース・ソフトウェアのセキュリティを確保することが可能とな
る。これまではこの脆弱性への対応が主に叫ばれてきたが、問題点の把握とあわせて
本段階を実行することで、より適切な対策を講じることが可能となると考えられる。
第 3 段階 運用管理
上記の通り脆弱性を評価し、対応を行ったとしても、対処しきれない問題点は存在
する。対処できない問題点に関しては運用管理という方法でその問題点を管理してい
くことが必要となる。オープンソース・ソフトウェアの運用は、自由度が高く、場合
よっては利用者に運用作業の多くを強いるものもある。例えば、バグに関する情報な
どは利用者本人が自分で収集しなければならない場合もある。いかにオープンソー
ス・ソフトウェアの運用管理をしていかなければならないのかは、オープンソース・
ソフトウェアを利用する上で、避けて通れない問題である。
【第 1 段階】
ソースコード検査
【第 2 段階】
脆弱性対応
【第 3 段階】
運用管理
運用ガイド
図7.
セキュリティ・フレームワーク
Ⅰ- 14
第Ⅰ部 オープンソース・ソフトウェアのセキュリティ確保
4.2. セキュリティ管理者
上記のフレームワークを通じて、セキュリティ上の問題点の管理をしていくことは決し
て容易なことではない。ソースコードを検査することは、現実問題、開発者でも困難で、
複雑な作業である。利用者全てが、上記のフレームワークを通じて、リスクの管理をして
いくのではなく、これらを統括して実施していくための「セキュリティ管理者」または「セ
キュリティ管理者グループ」の存在が重要である。「セキュリティ管理者」はフレームワー
クの各段階の知識を持ち、これらの実行を統括して行うものである。
4.3. 評価認定制度との関わり
セキュリティ・フレームワークは利用者自身でオープンソース・ソフトウェアの問題点
を管理するための枠組みである。その一方で、ソフトウェアのセキュリティを確保するた
めのメソドロジーが制度的には提供されている。Common Criteria[16]はセキュアなシステム
構築のための標準的なガイドラインであり、評価ガイドである。米国ではこうした基準が
政府の調達基準として適用されているところもある。Common Criteria はシステムのセキュ
リティ保証のためには非常に重要であり、システム開発におけるセキュリティ確保の上で
の標準になりつつある。オープンソース・ソフトウェアに対してもこうした Common Criteria
の適用が議論されているものもある。Common Criteria によってセキュリティ要件が整理さ
れ保障が認定されるようになれば、本フレームワークで示したようにユーザ自身がセキュ
リティのリスク管理を事細かく実施する必要はなくなり有益である。
しかしながら Common Criteria のオープンソース・ソフトウェアへの適用は疑問視される
面もある。Common Criteria の認定を受けるためには、様々なドキュメントの整備をはじめ
として相当のコストがかかる。オープンソース・ソフトウェアにおいてこのコストを誰が
負担するのかは大きな問題となる。さらにオープンソース・ソフトウェアは、商用のソフ
トウェアに比べても非常にバージョンアップが早く、頻繁に新しい機能の追加・拡張が行
われる。毎日パッチが提供されるものもある。こうしたオープンソース・ソフトウェアの
開発モデルは、ソフトウェア開発の利点であるが、Common Criteria を適用しようとした場
合には大きな足かせとなる。アップデートに応じて、要求されるセキュリティの項目が変
更されるため、再度 Common Criteria の認定を取得する必要がある。
このように、セキュリティの保障は制度的に非常に重要な側面であるが、オープンソー
ス・ソフトウェアにおいては必ずしも現実的な解とはいえない。おそらくオープンソース・
ソフトウェアの開発はさまざまな形式で行われるであろうし、セキュリティの保証を統一
的に付与することは困難だと思われる。開発者側の視点ではなく、利用者側の視点から、
このような多様なオープンソース・ソフトウェアのリスクを管理するためのフレームワー
クの構築は不可欠であり、今後オープンソース・ソフトウェアの利用が拡大していく中で
は重要になってくると考える。
Ⅰ- 15
第Ⅰ部 オープンソース・ソフトウェアのセキュリティ確保
5. ソースコード検査
オープンソース・ソフトウェアでは一般的な商用ソフトウェアと違い、ソースコードを
利用することが可能である。そこで、利用者側で、ソースコードを利用して、ソフトウェ
アに含まれているバグや脆弱性の検査を行うことが可能である。この検査の結果に従い、
脆弱性の評価を行い、システムのセキュリティ上の問題点を把握することは、利用者にと
って重要である。現在、ソースコードの検査を効率的に行うための幾つかのツールがオー
プンソース・ソフトウェアとして公開されている。本章では、ソースコードの検査により
セキュリティ上の脆弱性の調査するための技術について説明し、実際にどのような技術を
利用してソースコード中の脆弱性を検出するかについて説明する。
5.1. ソースコード検査の困難さ
オープンソース・ソフトウェアでは、設計書といったドキュメントが整備されることが
少ない。利用者はオープンソース・ソフトウェアのセキュリティ検査を行いたい場合には、
設計書等に依存しないソースコードのセキュリティ検査を行う。ソースコードのセキュリ
ティ検査は、ユーザが入力を行う個所といった、一般に脆弱性が発生しやすいとされる項
目から検査を行う。脆弱性が発生しやすいとされるのは特定のライブラリ関数の使用等が
代表的である。しかし、脆弱性が発生しやすいとされる項目が既知であったとしても、ソ
ースコード中の記述が脆弱であるかを判断するには多くの専門的な知識が必要である。た
とえば、以下のようなコードを考える。
1
char *getenv(const char *name);
2
char buf[1024];
3
char *printlibpath(void)
4
{
5
strcpy(buf, getenv("LD_LIBRARY_PATH"));
6
return buf;
7
}
上記の例では、5 行目が脆弱性の発生個所となる。この誤りが、数万行のソースコード内
の一行であった場合には、見つけ出すのことは容易ではない。また、分かり易さのために
要点となるコードをまとめて書いたが、間接的に脆弱性の要因となっている 2 行目の宣言
が脆弱性発生個所と同一のファイルに記述されているとは限らない。また、誤ったデータ
の型変換のようにソースコードを少し見た程度では、脆弱性の要因と判断することが難し
い場合もある。このような脆弱性を発見するには、専門的な知識を持つ技術者でも、多く
の時間を費やすことになる。利用者であるユーザが専門的な知識を有しており、ソースコ
ード検査のために十分な時間を費やすと考えるのは現実的ではない。しかし一方で、ユー
Ⅰ- 16
第Ⅰ部 オープンソース・ソフトウェアのセキュリティ確保
ザの大半がオープンソース・ソフトウェアを使用する際にその安全性を検証したいと考え
ている。そのため、ユーザが容易かつ効率的にソースコードの検査を行うための技術的支
援が必要とされる。
5.2. 効率的なソースコード検査技術
ソースコードの検査を技術的に支援する方策としては、専門知識の共有と精度の向上が
考えられる。ソースコードの専門知識の共有とは、技術者の専門的な技術をユーザが利用
可能な状態にすることである。精度の向上とは、ソースコードを構造的に分析することで
ある。これらをユーザが機械的に実行できるよう実装を行うことで効率的なソースコード
検査が可能となる。
5.2.1. 効率的なソースコード検査技術の分類
効率的なソースコードの検査技術は、その機能的特長から以下の 2 つに分類することが
可能である。
(1) パターンマッチング技術
脆弱性に関するデータベースを元に、ソースコード中に脆弱性を持つ関数や変数が
使用されているかどうかを検査する技術である。検査は、データベースに登録され
た脆弱性情報とソースコードのパターンマッチングによって行われる。
(2) 構文解析技術
ソースコードをそのまま検査するのではなく、構文解析を行い抽象化した構文木に
変換し、検査を行う技術である。従来の構文解析技術に、セキュリティ検査の為の
機能を付加したものである。セキュリティ検査のための付加的な注釈を使用し、こ
のデータ遷移の安全性まで検査可能である。
それぞれ検査のための技術が異なるため、検査可能な脆弱性の範囲が変わってくる。
5.2.2. 効率的なソースコード検査技術
これらの技術に対応するツールとして以下のようなものが挙げられる。
《パターンマッチング技術》
(1)
RATS (Rough Auditing Tool for Security)[17]
RATS は C/C++のソースコードにおける問題点を検査するためのツールである。
RATS はセキュリティ上危険な関数の呼び出しを検査するもので、C/C++の他、
Python や Perl、PHP をもサポートする。特徴的なのは、内部に保有する脆弱性デ
Ⅰ- 17
第Ⅰ部 オープンソース・ソフトウェアのセキュリティ確保
ータベースが XML で記述されていることである。このことにより、他のパターン
マッチング型のツールと比較して、ユーザはデータベースの拡張を柔軟に行うこ
とができる。検査結果は HTML 形式で出力することが可能となっており、利用す
るユーザの観点に立った開発が行われている。RATS の開発グループでは、ソース
コード検査ツールである Flawfinder との相互メンテナンスが計画されている。
DARPA の CHATS プログラムの支援を受けている。GPL として利用可能である。
(2)
ITS4 (It's the Software Stupid Source Scanner)[18]
ITS4 は静的に C 及び C++プログラムのコードをチェックするツールである。ITS4
では脆弱性データベースをユーザが拡張することが可能となっている。RATS と比
較しても、ユーザのデータベースの記述は容易となっている。検査結果が Microsoft
Visualu Studio 形式で出力される点と、ITS4 の利用が Emacs から行うことができる
点などから、開発者の視点に立ったツールといえる。その他に特徴的なのは、検
査が高速に行われるという点である。調査を行った５つのツールの中では、最も
検査速度が速かった。ソースコードは公開されているが、GPL ではなく、非商用
目的の利用に限って許可されている。
(3)
Flawfinder[19]
Flawfinder は、脆弱性データベースに基いて C/C++ のソースコードの検査を行う
ツールである。特徴的なのは、検査結果をリスクレベルでソートして出力するこ
とである。このことにより、ユーザは危険度の高い脆弱性の情報を優先的に得る
ことができる。Flawfinder の実装は、Python で行われており、脆弱性データベース
は Python スクリプトの内部に記述されている。このため、ユーザが脆弱性データ
ベースに変更するには直接 Python スクリプトに変更を加えることになる。また、
Pyrhon スクリプトを利用しているために、実行速度は遅い。一方で、本調査で行
った脆弱性の検出テストでは、唯一標準設定で全ての脆弱性を発見できたツール
である。現在、RATS と相互メンテナンスを行う試みが計画されている。GPL とし
て利用可能である。
《構文解析技術》
(4)
Splint (LCLint)[20]
Splint は静的に C プログラムのコードをチェックするツールである。基礎技術とし
て C 言語の構文解析ツールである lint が用いられている。Lint による調査に加えて、
セキュリティ上重要と思われる個所の詳細な検査が可能である。コメント文に
Splint 独自の記述を行い、この記述をシースコードと併せて解析することで詳細な
調査を実現できる。GPL として利用可能である。
Ⅰ- 18
第Ⅰ部 オープンソース・ソフトウェアのセキュリティ確保
(5)
Cqual[21]
Cqual は C プログラムのデータ型に着目した分析ツールである。Cqual はもともと
西暦 2000 年問題検出のためのツールを拡張したものであり、これにセキュリティ
チェックの機能が付加されている。このセキュリティチェックの機能が Cqual の特
徴であり、C 言語のデータ型を拡張することで検査を可能にしている。この拡張は、
ユーザ定義の type qualifier と呼ばれる型修飾子で行われる。ユーザは型修飾子をソ
ースに追加する。Cqaul は、追加された型修飾子の遷移が予め定義したルールに従
っているかについて、抽象構文木を用いて検査する。定義したルールに従ってい
ない個所が、データ型に矛盾が生じる個所として、ユーザに警告される。Cqual は
GPL で利用可能である。
5.3. 効率的なソースコード検査技術で検出される脆弱性
パターンマッチング型の検査ツールでは、脆弱性の可能性の高いライブラリ関数の使用
を検出する。主に検出されるライブラリ関数は以下に示すとおりである。
・ バッファーオーバーフローを引き起こす可能性の高い関数の使用
・ レースコンディションを引き起こす可能性の高い関数の使用
・ UNIX システムコール関数の使用
・ 精度の低い乱数生成関数の使用
構文解析型の検査ツールでは、セキュリティ上の問題の生じやすい記述を検出する。主
に検出される事項は以下に示すとおりである。
・ 不正な null pointer への参照の検出
・ 未定義の記憶領域の使用、適切でない定義の記憶領域へのリターンの検出
・ 型の不一致の検出
・ メモリ・リークや Dangling reference の使用を含む、メモリー管理エラーの検出
・ 関数のインタフェースと矛盾する変数の使用の検出
・ 無限ループや網羅されていない case 構文の使用といった問題の可能性が高い実装
の検出
・ バッファーオーバーフローの検出
・ 危険なマクロの記述の検出
・ 変数・関数の命名規則違反の検出
・ データ遷移の矛盾の検出
・ 危険な型変換の検出
Ⅰ- 19
第Ⅰ部 オープンソース・ソフトウェアのセキュリティ確保
検査ツールがこれらの脆弱性全てに対応できないことに注意が必要である。本章で取り
上げたツールでも、これらの脆弱性を含むコードを検出できるのは部分的である。以下は
第Ⅱ部にて行った、脆弱性の検出テストの結果である。5.2.2で取り上げたツールが、
CERT/CC 等に警告された脆弱性に対してどの程度検出が行うことができるかを評価したも
のである。該当する脆弱性の警告だけを得ることが可能なツールはない。従って、各ツー
ルにおける出力の分析を行うことが必要である。このため、ツールによる検査を行う場合
には、そのツールの特性を理解し、対応している脆弱性や検査技法について十分に理解し
たうえで、利用しなければならない。
#
1
2
3
4
5
6
アプリケーション
bind8.1.1
qpopper2.4
elm2.3.0
imapd3.6
Apache1.1.3
wu-ftpd2.6.0
RATS
○
○
○
△
△
×
ITS4
○
○
○
○
△
○
Flawfinder
○
○
○
○
○
○
Splint
△
△
×
×
△
×
Cqual
×
×
×
×
×
×
○：正常に検出を行うことができた。
△：検出を行うにあたって注意点があるが、検出は可能である。
×：検出を行うことができなかった。
図8.
検査ツールによる脆弱性検出実験結果
5.4. 何を利用すればいいのか
実際に検査を行うに当たって、どのような技術を適用していくかは難しい問題である。
何故なら、検査ツールの効果は検査ツール利用者のスキルに依存するためである。パター
ンマッチング型のツールを用いた場合、利用者でも検査は比較的容易に行うことができる。
しかし、誤検出の数も多く検査結果の分析には注意が必要である。一方、構文解析型のツ
ールでは、誤検出は比較的少ないが、検査の実施に対象となるアプリケーションの知識が
必要となる。厳密な検査を実施するには、ソースコードを構造的に分析を行う構文解析型
のツールを用いるのが望ましい。一般的なアプリケーションのユーザが検査を実施するに
は、パターンマッチング型を用いるのが望ましい。より多くのユーザがオープンソース・
ソフトウェアに潜在する脆弱性の可能性を把握するには、パターンマッチング型のツール
を使用することが妥当と考えられる。調査の結論としては、ライセンス・利便性・検出の
容易さの観点から、パターンマッチング型ツールの 1 つである RATS を用いることを推奨す
る。しかし、RATS においても全ての脆弱性を検出する訳ではない。従って、検出結果に基
づく分析を十分に行った上で利用しなければならない。
Ⅰ- 20
第Ⅰ部 オープンソース・ソフトウェアのセキュリティ確保
5.5. 効率的なソースコード検査技術の課題
現状のソースコード検査技術には、以下のような課題があると考えられる。
(1) 精密な検査を行うためにユーザに必要とされる技術・手間が多すぎる。ツールによっ
ては検査の実施そのものが困難であり、実施が容易なツールにおいても検査結果の分
析に膨大な時間を要することがある。これらの点を改善し、容易かつ効率的な検査を
可能とすることが課題である。
(2) 検査ツールによって、脆弱性に対する具体的な改善方法の提示がなされていない。指
摘が行われた脆弱性の個所に関しての具体的な改善方法が提示されることで、ユーザ
はオープンソース・ソフトウェアにおける脆弱性のリスクの把握でなく、検査の段階
で安全性を確保することが可能になる。
(3) パターンマッチング技術は、利用が容易であり高速に動作する。しかし、誤検出も非
常に多いため、ユーザは出力結果の分析を行わなければならない。誤検出の回避を行
うための技術の模索が課題である。
(4) 構文解析技術では、精密な検査が可能であるが、利用が困難である。ソースコードに
対する検査項目の記述の簡略化・自動化が可能になることが課題である。
さらに技術的な課題だけでなく、以下のような課題もある。
(5) これらのツールで検出可能な脆弱性の範囲の限定が行われておらず、脆弱性としてど
ういったものがあり、その脆弱性が及ぼす影響を及ぼすかについて、体系だった議論
も行われていない。これらのまとまった情報があれば、検査ツールの利用者は出力結
果の分析をより詳細に行うことが可能である。
(6) 商用ソフトウェアや、一般論としてのソースコード検査や監査についての議論は行わ
れているが、オープンソース・ソフトウェアに特化した検査技法の議論は行われてい
ない。これらの議論が行われることで、より効率的な検査方法を行うことが可能であ
る。
ソースコード検査ツールには幾つかの課題があるが、オープンソース・ソフトウェアが
潜在的に保有する脆弱性の可能性を事前に把握する試みは必要である。ユーザが、使用す
るソフトウェアにどの程度の危険性が存在するかを、完全でないにしろ把握することで、
問題発生時に対応を迅速に行うことが可能になる。 米国の Sardonix security portal[22]のよう
にオープンソース・ソフトウェアのソースコード監査の情報の公開を試みている事例もあ
り、ユーザは自ら検査を行うだけでなく、適宜このような情報を利用することで、より効
率的にリスクを把握することが可能となる。これらの情報を基に、オープンソース・ソフ
トウェアの便利性と共に内在する危険性についても客観的に評価を行うことが望まれる。
Ⅰ- 21
第Ⅰ部 オープンソース・ソフトウェアのセキュリティ確保
6. 脆弱性対応
オープンソース・ソフトウェアのセキュリティを確保するためには、前章で説明したソ
ースコードの検査技術だけでは不十分である。たとえソースコードの検査によってセキュ
リティに関連する問題を検出したとしても、それを利用者側で修正することは、事実上困
難で、ソースコードを直接修正することなく、検査によって検出されたセキュリティの問
題に対応するための技術が重要となる。ここでは、オープンソース・ソフトウェアのセキ
ュリティを確保するために、利用者がソースコードそのものを修正することなく、セキュ
リティを確保するための技術について説明し、実際にどのような技術を利用して実行コー
ドレベルでセキュリティを確保していけるのかについて説明する。
6.1. 脆弱性への対応の困難さ
脆弱性を実際に修正することは、専門家でも困難な作業である。5章で示したように脆弱
性の存在が確認できる箇所はソースコード検査ツールなどによって比較的容易に検出でき
る。しかしながら、検出した脆弱性を修正しようとすると、実際にどのように修正すれば
安全になり、現状のソフトウェアに影響がないのかを把握しなければならない。脆弱性へ
の対応の困難さについて、C 言語におけるバッファーオーバーフローの脆弱性を例にとって
説明する。C 言語には利用すべきではない標準ライブラリ関数が多数ある。実際に多くのオ
ープンソース・ソフトウェアにおいてこれらの関数が利用されており、CERT/CC 等で報告
されている情報もこれに関連するものは多い。以下は、脆弱性のあるプログラムの例であ
る。
1
void dunc(char *input) {
2
char buffer[256];
3
strcpy(buffer, input);
4
}
ソースコードの検査技術などによって、この例の脆弱性は比較的容易に検出することが
可能である。このプログラムでは、関数が受け取った文字列が 255 文字以上あると、バッ
ファーがオーバーフローする。これを単純な方法で修正した例を以下に示す。
1
void dunc(char *input) {
2
char buffer[256];
3
strncpy(buffer, input, 256);
4
}
Ⅰ- 22
第Ⅰ部 オープンソース・ソフトウェアのセキュリティ確保
ここでは、様々なガイドで言われているように strcpy() 関数の代わりに、文字列の長さを
チェックするための機能のついた、strncpy() 関数を利用している。この関数は 256 以上の
文字列をコピーしないので、一見すると安全に思われる。しかしながら、この修正は別の
問題を引き起こす。文字列の終端記号”¥0”が書き込まれない場合があるのだ。もし”¥0”が書
き込まれない状況で、このバッファーの値を利用した場合には、別のエラーが生じること
となる。
このように、脆弱性のあるコードの場所を特定したとしても、これを修正することは困
難である。特に利用者が、こうした修正をすることは現実的ではない。行った修正が別の
問題を引き起こすことになっては本末転倒だからである。
6.2. セキュアな実行コード生成・実行環境技術
そこで直接ソースコードを修正することなく、ソフトウェアの脆弱性をカバーすること
ができる技術が重要となる。このような技術としては、セキュアな実行コード生成・実行
環境技術がある。セキュアな実行コード生成・実行環境技術とは、オープンソース・ソフ
トウェアを実行コードレベルでセキュアにするための技術を指す。この技術では、基本的
に作成されたソフトウェアを利用者は直接修正する必要はなく、自動的にセキュアな実行
コードを作成したり、実行コードを安全に実行するための環境を用意することができるの
である。これらの技術の利用により、利用者は直接的にプログラムコード中の脆弱性を修
正する必要がなくなり、比較的容易に脆弱性への対策を施すことが可能である。
6.2.1. セキュアな実行コード生成・実行環境技術の分類
セキュアな実行コードの生成・実行環境技術は、その機能的特長から以下の 3 つに分類
することが可能である。
(1) コンパイラ技術
GCC などのコンパイラを拡張して、セキュアなコードを生成する技術
(2) カーネル技術
プログラムの実行環境であるオペレーティングシステムそのものを拡張して、プロ
グラムをセキュアに実行するための環境を提供するための技術
(3) ライブラリ技術
アプリケーションや、オペレーティングシステムそのものを拡張するのではなく、
アプリケーションで利用されるライブラリを拡張し、プログラムをセキュアに実行
するための技術
Ⅰ- 23
第Ⅰ部 オープンソース・ソフトウェアのセキュリティ確保
それぞれの技術は、セキュリティ確保のための技術を実装するレイヤーが変わってくる。
基本的に保護できる脆弱性の範囲は変わらないが、適用できる範囲や、適用時の速度等に
違いがある。
6.2.2. セキュアな実行コード生成ツール・実行環境
これらの技術に対応するツールとして以下のようなものが挙げられる。
《カーネル技術》
(1) Qpenwall[23]
Openwall と呼ばれる Linux ディストリビューションのためのセキュリティ・パッチ
である。バッファーオーバーフロー対策のために、ユーザのスタック領域を実行不
可能にするための機能や、/tmp へのシンボリックリンクの制限、/proc の利用制限な
どをカーネルパッチとして提供している。
《コンパイラ技術》
(2) StackGuard[24]
コンパイラレベルでバッファーオーバーフロー対策を行うもの。“カナリア”と呼ば
れるランダムな値をスタックの戻り値の直前に埋め込み、その値が不正に書き換え
られていないかをチェックすることでバッファーオーバーフローを検出・防御する。
(3) Bounds Checking[25]
コンパイラレベルでバッファーオーバーフロー対策を行うもの。GCC のフロントエ
ンドを改変して、チェック機能を埋め込んだもの。コード中にチェック機能のため
のコードを埋め込む。
(4) Stack Smashing Protector[26]
日本 IBM で研究されているもので、StackGuard と同様の機能を提供する。
《ライブラリ技術》
(5) FreeBSD stack integrity patch[27]
C の危険なライブラリ関数を置き換えるためのライブラリのパッチを提供する。バッ
ファーオーバーフローを引き起こす可能性のある文字列操作系のライブラリ関数を
セキュアな関数で置き換えるパッチを提供する。
Ⅰ- 24
第Ⅰ部 オープンソース・ソフトウェアのセキュリティ確保
(6) Libsafe[28]
C のライブラリベースでバッファーオーバーフローなどのセキュリティ上の問題を
回避するためのライブラリである。ソースコードを変更せず、シェアードライブラ
リを置き換えるため、既存のシステムにそのまま適用が可能である。
6.2.3. セキュアな実行コード生成・実行環境技術でカバーされる脆弱性
このように様々なツールが提供されてきてはいるものの、脆弱性全体に対してはまだ十
分にカバーし切れているとは言えない。以下は第Ⅲ部にて行った、脆弱性の検出テストの
結果である。6.2.2で取り上げたツールが、CERT/CC 等に報告された脆弱性に対してどの程
度効果があるのかを評価したものである。特定の脆弱性に対して、完全にそれをカバーで
きるツールというものはあまりない。そのため、ツールによって脆弱性への対応を行う場
合には、そのツールの効果、対応する脆弱性等を十分に理解したうえで、利用しなければ
ならない。
#
1
2
3
4
5
6
アプリケーション
bind8.1.1
qpopper2.4
elm2.3.0
imapd3.6
Apache1.1.3
wu-ftpd2.6.0
標準
Root
Root
Root
Root
Fi l e
Root
SG
Core
Halt
Core
Halt
Fi l e
Core
SSP
Halt
Halt
Halt
Halt
Fi l e
Core
BC
Core
Halt
Halt
Halt
Fi l e
Core
Root → ルート権限取得成功
File → File 権限の奪取
図9.
OWL
Core
Halt
Halt
Halt
Halt
Core
LS
Halt
Halt
Halt
Halt
Fi l e
Root
Core → コアダンプ終了
Halt → プログラム終了
アプリケーションの脆弱性検出結果
6.3. 何を利用すればいいのか
実際に対策を行うに当たって、どのような技術を適用していくかは難しい問題である。
セキュリティの面からすれば、いかに安全性を確保できるかが重要であるが、実際の利用
環境においてはパフォーマンスや利便性等とのトレードオフがある。調査の結論としては、
実行コードの安全性を高めるために、2 つのツールを(Stack Smashing Protector, Libsafe)選択
して利用することを推奨する。（詳細は利用ガイド参照）しかしならが6.2.3で述べたように
すべての脆弱性に対して効果があるわけではないので、どの部分がカバーできずに脆弱性
のリスクが残るのかを十分把握した上で利用しなければならない。
6.4. セキュアな実行コード生成・実行環境技術の課題
現状のセキュアな実行コード生成・実行環境技術には、以下のような課題があると思わ
れる。
Ⅰ- 25
第Ⅰ部 オープンソース・ソフトウェアのセキュリティ確保
(1) 脆弱性に関連して発生する攻撃を検出することはできるものの、攻撃そのものを阻止
し、プログラムを正常に動作し続けるができない。そのため DoS 攻撃などに対しては
効果がない。
(2) コンパイラ技術は非常に有望な技術ではあるが、ソースプログラムをそれぞれ再コン
パイルし直す必要があり、利用上の困難さが発生する。
(3) 適用する技術によっては、その適用によってシステムに弊害を発生するものもある。
さらに技術的な課題だけでなく、以下のような課題もある。
(4) これらのツールがどういった脆弱性に対して効果があり、どういった脆弱性に対して
効果がないのかといった情報源が乏しい。こういった情報が広くオープンにされてい
れば、利用者はこうした情報を参照しながら脆弱性への対応を行うことが可能である。
いくつかの課題はあるものの、バッファーオーバーフロー攻撃などに関しては、現状の
技術でも十分効果があると思われる。今後、より広範囲での脆弱性への対応技術が開発さ
れる必要がある。6.2.2には含まなかったが、不正な入力による攻撃などに対する保護機能
の開発なども行われており、今後これらの技術が整備されていくと思われる。これらの技
術の効果を見極め、前章で説明したソースコードの検査の結果に対して適切に対応してい
くことにより、脆弱性への対策を十分に行っていくことが望まれる。
Ⅰ- 26
第Ⅰ部 オープンソース・ソフトウェアのセキュリティ確保
7. 運用管理
オープンソース・ソフトウェアは、商用のソフトウェアとは異なる開発方法をとってい
る。オープンソース・ソフトウェアは、インターネットを利用して協調的に開発されてお
り、頻繁にバージョンアップがなされる。こうしたオープンソース・ソフトウェアの特徴
は、オープンソース・ソフトウェアを運用していく場合にも、従来の商用ソフトウェアと
は違った運用方法が求められる。例えば、オープンソース・ソフトウェアでは、利用者側
でバージョンアップ情報を把握し、適切にソフトウェアのバージョンを実施しなければな
らない。また、利用しているソフトウェアのセキュリティ問題などは、利用者で積極的に
情報を収集し、対応していく必要がある。オープンソース・ソフトウェアを情報インフラ
として利用していくためには、セキュリティを十分考慮した運用管理が必要になってくる。
本章では、利用者がオープンソース・ソフトウェアをセキュアに利用するにあたっての保
守・運用方法及びコミュニティとの関わり方についてまとめる。（詳細は第Ⅳ部）
7.1. オープンソース・ソフトウェア運用モデルの分類
オープンソース・ソフトウェアの運用を以下の 3 モデルに分類して、それぞれのモデル
においてどのように運用をしていかなければならないかについて検討した。
（モデル 1） 自組織のみで情報の収集と対応をするケース
セキュリティ管理者が自組織のみでオープンソース・ソフトウェア情報をコミュニテ
ィ、あるいはセキュリティ情報提供組織から収集し、その対応を行うケースである。
OSSコミュニティ
アナウンス
組織メンバ
セキュリティ管理者
（エンドユーザ）
セキュリティ情報
提供組織（無償）
対策
管理サーバ
図10. 自組織のみで情報の収集と対応をするケース
（モデル 2）有償外部リソースから情報を収集して、自組織で対応をするケース
セキュリティ管理者が有償の外部リソースである情報提供ベンダ、ディストリビュー
タ、あるいはシステムインテグレータから情報のみを収集し、対応については自ら行
うケースである。
Ⅰ- 27
第Ⅰ部 オープンソース・ソフトウェアのセキュリティ確保
OSSコミュニティ
アナウンス
情 報 提 供 ベ ンダ （有 償 ）
デ ィス トリビュー タ
シス テム インテグレー タ
組 織 メンバ
セキ ュリティ管 理 者
（エンドユ ー ザ ）
対策
管理サーバ
セ キ ュリティ情 報
提 供 組 織 （無 償 ）
図11. 有償外部リソースから情報を収集して、自組織で対応するケース
（モデル 3） 有償外部リソースに情報の収集と対応を依頼するケース
セキュリティ管理者が有償の外部リソースである情報提供ベンダ、ディストリビュー
タ、あるいはシステムインテグレータから情報を収集すると共に、その対応も外部へ
委託するケースである。
OSSコミュニティ
情報提供ベンダ（有償）
ディストリビュータ
システムインテグレータ
アナウンス
組織メンバ
セキュリティ管理者
（エンドユーザ）
管理サーバ
対策
セキュリティ情報
提供組織（無償）
図12. 有償外部リソースに情報の収集と対応を依頼するケース
3 つのモデルにオープンソース・ソフトウェアの運用形態を分類したが、どのモデルに従
ってオープンソース・ソフトウェアの運用をしていくのかによって大きく運用作業の項目
が異なる。これらのモデルと運用時に実施すべき運用項目を整理していくことによって、
オープンソース・ソフトウェアを利用していくにあたり、どのように運用を考えていけば
よいのかについて取りまとめる。
7.2. オープンソース・ソフトウェアをセキュアに保つための運用方法
3 つのモデルを通じてセキュリティ管理者が行わなければならないことを整理する。オー
プンソース・ソフトウェアの運用を行う場合に、実施しなければならない項目としては以
下の 3 つが重要である。
(1) セキュリティ情報の収集
(2) セキュリティ情報への対応（パッチ適用等）
(3) インシデントへの対応
Ⅰ- 28
第Ⅰ部 オープンソース・ソフトウェアのセキュリティ確保
7.2.1. セキュリティ情報の収集
セキュリティ情報の収集リソースとして、主にオープンソース・ソフトウェアコミュニ
ティ、およびセキュリティ情報提供組織を取り上げる。オープンソース・ソフトウェアコ
ミュニティは、セキュリティ情報提供を中心にした組織でないが、オープンソース・ソフ
トウェアコミュニティ全般の情報が集約されており、情報収集の要となるので取り上げる
ことにする。本節では、下記の表 1で示す 5 つの分野に情報提供組織を分類し、それぞれど
のような情報が提供されているのかについて整理する。各分野は、取り扱う分野、提供す
る情報なども異なるほか、情報の取得時のコストも変わってくる。情報収集の際には、こ
れらに注意し、自身の環境にあった情報提供元を選択する必要がある。
情報提供組織の分類
分野
オープンソース・ソフトウェ
特定のもの
アコミュニティ
情報
コスト
脆弱性情報・改善策・パッチ等
なし
脆弱性情報・改善策等
なし
セキュリティ情報提供組織
一般
ディストリビュータ
ディストリビ
脆弱性情報・改善策・パッチ等
ューション
なし*
システムインテグレータ
一般
脆弱性情報・改善策等
あり*
セキュリティ情報提供ベンダ
一般
脆弱性情報・改善策等
あり*
* 一部例外もある。
表1.
セキュリティ情報提供組織の分類
7.2.2. セキュリティ情報への対応
ここでは、セキュリティ情報への対応として、パッチの適用手順について述べる。セキ
ュリティ情報に基づくタイムリーなパッチの適用は、IT システムの可用性、機密性、完全
性の運用を維持するために、非常に重要である。新しいパッチは、異なるアプリケーショ
ンごとに頻繁にリリースされ、それは、全ての新しいパッチに精通する経験を積んだシス
テム管理者にとってさえも、多くの場合困難であると言える。
脆弱性の軽減に対処するために、パッチとセキュリティに関するセキュリティ管理者グ
ループを編成することが米国において推奨されている。ここでは、[29]のレポートを参考に
しながら、オープンソース・ソフトウェアのセキュリティ・パッチの運用手順について説
明する。この手法は、オープンソース・ソフトウェアに限らず商用ソフトウェアについて
も共通であり、オープンソース・ソフトウェア同様に効果が期待される。運用手順は、以
下の 9 項目からなる。
Ⅰ- 29
第Ⅰ部 オープンソース・ソフトウェアのセキュリティ確保
1.
組織のソフトウェア資産目録の作成
2.
新しく発見された脆弱性およびセキュリティ・パッチの識別
3.
優先的なパッチの適用
4.
組織に特有のパッチ・データベースの作成
5.
パッチ・テスト
6.
パッチおよび脆弱情報の配布
7.
ネットワークおよびホスト脆弱性スキャンによるパッチ適用の確認
8.
脆弱性データベースを利用したシステム管理のトレーニング
9.
パッチの自動適用
7.2.3. インシデントへの対応
オープンソース・ソフトウェアであってもそうでなくてもインシデント対応時の手順に
変わりはない。 インシデントへの対応としては、コンピュータ緊急対応センター
(JPCERT/CC)が公開している、以下のインシデント発見時の対応手順（16 項目）がある[30]。
1) 冷静に対処する
2) 手順の確認
3) 作業記録の作成
4) 責任者、担当者への連絡
5) 事実の確認
6) スナップショットの保存
7) ネットワーク接続やシステムの遮断もしくは停止
8) 影響範囲の特定
9) 渉外、関係サイトへの連絡
10) 要因の特定
11) システム復旧
12) 再発防止策の検討
13) 監視体制の強化
14) 作業結果の報告
15) 作業の評価、ポリシー・運用手順の見直し
16) JPCERT/CCへの報告
オープンソース・ソフトウェアを利用していると言ってもインシデントへの対応自体に
大きな違いがあるわけではない。しかしながら、上記の対応手順のうち、何を自分で行い、
何を運用委託先に任せるのかが変わってくる。7.1で述べた「運用モデルの分類」の違いに
より、対応手順の分担をモデルごとに整理すると以下のようになる。
Ⅰ- 30
第Ⅰ部 オープンソース・ソフトウェアのセキュリティ確保
No.
1
対応項目
冷静に対処する
2
手順の確認
3
作業記録の作成
4
責任者、担当者への連絡
5
事実の確認
6
スナップショットの保存
7
8
ネットワーク接続やシステムの
遮断もしくは停止
影響範囲の特定
9
渉外、関係サイトへの連絡
10
要因の特定
11
システム復旧
12
再発防止策の検討
13
監視体制の強化
14
作業結果の報告
15
作業の評価、ポリシー・
運用手順の見直し
JPCERT/CC への報告
16
モデル 1
モデル 2
モデル 3
○
○
○
○
○
○
○
○
○
○
○
○
○
○
−
○
○
−
○
○
−
○
○
−
○
○
○
○
△
△
○
○
△
○
△
△
○
○
−
○
○
−
○
○
○
○
○
○
自組織で対応する項目に “○” 印で表示
自組織で一部対応する項目に “△” 印で表示
外部リソースへ委託する項目に “−” 印で表示
モデル 1 ･･･ 自組織のみで情報の収集と対応をする場合
モデル 2 ･･･ 有償外部リソースから情報を収集して、自組織で対応する場合
モデル 3 ･･･ 有償外部リソースに情報の収集と対応を依頼する場合
表2.
オープンソース・ソフトウェアにおけるインシデント対応表
このように、運用モデルによって対応すべき項目が変わってくる。利用者はこれらの違
いを認識し、自組織の運用モデルに合った手順に従わなければならない。
Ⅰ- 31
第Ⅰ部 オープンソース・ソフトウェアのセキュリティ確保
7.3. まとめ
オープンソース・ソフトウェアは、商用ソフトウェア利用時の運用と比較して、自由度
の高い運用方法の選択をエンドユーザにもたらしてくれる。本報告書では、オープンソー
ス・ソフトウェア運用モデルを以下の 3 つに分類して説明してきた。またオープンソース・
ソフトウェアの運用時にセキュリティ上実施すべき項目を３つ取り上げた。これらを整理
すると以下のようになる。
作業項目
モデル 1
モデル 2
モデル 3
セキュリティ
情報収集
自組織で対応
外部リソースで対応
外部リソースで対応
セキュリティ情
報への対応
自組織で対応
自組織で対応
外部リソースで対応
対応項目 10, 12 について
は、自組織が中心となり外
部リソースから情報を入
手。それ以外は、自組織で
対応。
対応項目のうち、5, 6, 7, 8,
13, 14 については外部リソ
ースを中心に対応。また、
項目 10, 11, 12 については、
自組織が中心となり外部リ
ソース情報を入手。それ以
外は、自組織で対応。
インシデント
への対応
モデル 1
モデル 2
モデル 3
自組織で対応
･･･ 自組織のみで情報の収集と対応をする場合
･･･ 有償外部リソースから情報を収集して、自組織で対応する場合
･･･ 有償外部リソースに情報の収集と対応を依頼する場合
表3. オープンソース・ソフトウェア運用モデルと作業項目対応のまとめ
表 3から分かるように、セキュリティ情報の収集については、自組織のみならず、セキュ
リティ情報提供サービスを行っている外部リソースを活用することで、複数の運用形態を
とることが可能である。また、セキュリティ情報対応に関しては、外部リソースへ依頼す
ることで、自組織の役割を最小化することができる。インシデントへの対応では、対応項
目に応じて、外部リソースの活用状況が異なってくる。モデル 1 は自組織での対応を想定
しているが、モデル 2 では、対応項目 10,12 について、セキュリティ情報を外部から積極
的に入手する。さらにモデル 3 では、入手した情報を元に特定原因を洗い出し、事前に決
められている方針に基づいて、対応を外部リソースへ依頼する。
Ⅰ- 32
第Ⅰ部 オープンソース・ソフトウェアのセキュリティ確保
8. まとめ
オープンソース・ソフトウェアのセキュリティに関しては様々な議論があることは述べ
た。その結果、明らかなことは、オープンソース・ソフトウェアはソースコードを見るこ
とが可能であるため、利用者側でセキュリティを高めることが可能であるというメリット
がある。裏返せばソースコードが見えるということは、悪用する人にとっても有利な点と
なりうるかもしれない。ソフトウェアの安全性を高めていく上では、オープンソース・ソ
フトウェアの大原則であるソースコードの開示は非常に大きな力となる。だからといって、
単にソースコードが公開されたとしても、必ずしもソフトウェアが安全となるというもの
ではない。多くの人はソースコードを閲覧しないかもしれないし、たとえ閲覧しても脆弱
性につながるようなコードの問題に気づかないかもしれない。また、たとえ気づいたとし
てもどのように解決したらいいのか、また回避したらいいのかわからないのが現状である。
本報告書では、オープンソース・ソフトウェアのメリットを踏まえ、利用者側でどのよ
うにソフトウェアのセキュリティを確保していけばいいのかについて検討した。オープン
ソース・ソフトウェアのソースコードの開示を利用して、現在の技術でどのようなことが
でき、どのような脆弱性を回避することが可能かについて検討した。
ソースコードの検査技術は、ソースコードレベルでの脆弱性の検出を効率的に行うよ
うにサポートしてくれる。その成熟度はまだ低いものの、ソースコードの検査という非
常に煩雑な作業を効率的に行うための基盤として大変に重要であり、利用者の立場から
すれば、よく知られた脆弱性が、利用するオープンソース・ソフトウェアに含まれてい
ないかを簡易的にチェックするためにも有益である。
セキュアな実行コード・実行環境技術は、ソースコード検査の結果を踏まえて、オー
プンソース・ソフトウェアの安全性を高めるための技術として非常に重要である。利用
者側でソースコードを検査しても、実際にその問題を解決することは困難である。その
ため利用者がソースコードを修正することなく、オープンソース・ソフトウェアの安全
性を高めていくための技術は非常に重要となってくる。本報告書では、こうした技術を
取り上げ、実際のオープンソース・ソフトウェアに適用してその効果を調査した。その
結果、セキュアな実行コード・実行環境技術は、すべての脆弱性に対応はできないもの
の、特定の脆弱性には非常に効果がある。少なくともソースコードの検査で検出される
エラーをカバーするための技術としては整備が進んできている。
Ⅰ- 33
第Ⅰ部 オープンソース・ソフトウェアのセキュリティ確保
技術的な対策だけでは、十分ではない。ソフトウェアのセキュリティは固定的なもの
ではなく、時間とともに変化するものである。この変化に対応するためには、ソフトウ
ェアを適切に運用していくことが重要である。ソフトウェアに脆弱性が検出された場合
は、速やかにパッチをあて、ソフトウェアをアップデートしなければならないし、そう
した情報を積極的に利用しなければならない。オープンソース・ソフトウェアの運用は、
商用のソフトウェアに比べて、自由度が高い。つまり、利用者が自分でさまざまな対応
を取ることが可能である。そのため、どのような体制でオープンソース・ソフトウェア
を運用していくかについて、コストや体制を踏まえて検討する必要がある。本報告書で
は 3 つのオープンソース・ソフトウェア運用のモデルを提案し、それぞれにおいて利用
者がどのようなことをしなければならないのかについて取りまとめた。どのモデルで実
際に自己のオープンソース・ソフトウェアを運用していくかによって、コストも異なれ
ば、自組織に構築しなければならない体制も実施すべき作業項目も変わってくる。
8.1. セキュアなオープンソース・ソフトウェアの利用環境の構築に向けて
本報告書で述べたフレームワークは、利用者の立場からすれば、技術的には高度で適用
できない場合もある。また、利用者が個別に同じオープンソース・ソフトウェアのセキュ
リティを検討することは効率的ではない。こうしたことを考えると、本フレームワーク自
身もオープンなものとすることが重要である。つまり、ソースコードの検査や、セキュア
なコード生成・実行環境技術などについての情報をオープンに公開・利用できる環境が重
要になると思われる。米国では、Sardonix[22]のように、オープンソース・ソフトウェアのソ
ースコード検査の結果を公開している組織などが政府の支援の下で運営されている。こう
した組織により、オープンソース・ソフトウェアのセキュリティに関しての情報を共有す
るための場の構築が重要である。
各国政府もオープンソース・ソフトウェアの利用を積極的に推進していく中で、こうし
た環境の構築が求められている。特にオープンソース・ソフトウェアを調達する過程にお
いて、オープンソース・ソフトウェアそのものに、Common Criteria などを適用することは
困難である。前述したようにオープンソース・ソフトウェアにはその責任主体が明確でな
いという問題点がある。そのために政府がオープンソース・ソフトウェアの調達にセキュ
リティの要件を厳密に盛り込んだとしても、この要件を誰が満たすのかは不明確である。
オープンソース・ソフトウェアの開発側のみに、セキュリティの保証を要求する枠組みで
は限界がある。本報告書で述べたように利用者側でのセキュリティ確保の枠組みも必要で
ある。政府レベルがこうした枠組みを積極的に支援していくことも重要となる。
利用者側の視点から、オープンソース・ソフトウェアのセキュリティを確保していくた
めの環境の整備が整うことで、多くの人が利用者の視点からオープンソース・ソフトウェ
アのセキュリティ確保のための活動に参加していけるようになる。
Ⅰ- 34
第Ⅰ部 オープンソース・ソフトウェアのセキュリティ確保
オープンソース・ソフトウェアのセキュリティ確保の技術については、まだ多くの研究
開発に必要な面があるのと同時に、こうした技術の情報を共有し、実際のオープンソース・
ソフトウェアの利用時に活かしていけるための制度的な対策も必要とされる。
本報告書が、オープンソース・ソフトウェアを利用しようとする人の一助となれば幸い
である。
Ⅰ- 35
第Ⅰ部 オープンソース・ソフトウェアのセキュリティ確保
参考文献
[1]
Categories of Free and Non-Free Software,
http://www.gnu.org/philosophy/categories.html
[2]
OSI, http://www.opensource.org/
[3]
Lake David, “Asleep at the wheel”, The Industory Standard, December 2000.
[4]
David A. Wheeler, “Secure Programming for Linux and Unix HOWTO”, March, 2002.
[5]
Rishab A. Ghosh, Bernhand Krienger, Ruediger Glott, Gregorio Robles, “Open
Source Software in the Public Sector: Policy within the European Union”, Free/Libre
and Open Source Software: Survey and Study. Part2B, University of Maastricht,
June 2002.
http://www.infonomics.nl/FLOSS/report
[6]
Bugtraq. http://online.securityfocus.com/archive/1
[7]
CERT/CC, http://www.cert.org/.
[8]
CVE, http://www.cve.mitre.org/
[9]
Steven M. Christey , Robert A. Martin , “A Progress Report on the CVE Initiative”,
FIRST 14th Annual Computer Security Incident Handling Conference, Kona, Hawaii,
USA , June 24, 2002.
http://www.cve.mitre.org/docs/docs2002/prog-rpt_06-02/CVE_FIRST_paper.pdf
[10] William A. Arbaugh, William L. Fithen, Jobn McHugh, “Windows of Vulnerability: A
Case Study Analysis”, IEEE computer, 2000.
[11] David Evans, David Larochalle, “Improving Security Using Extensible Lightweight
Static Analysis”, IEEE software, January 2002.
[12] David Wagner, J S, Foster, Eric A. Brewer, Alexander Aiken, “A First Step Towards
Automated Detection of Buffer Overrun Vulnerabilities”, Proc. 2000 Network and
Distributed System Security Symp., Internet Society, Reston, Va., 2000.
http://www.isoc.org/ndss2000/proceedings
[13] Eric S. Raymond, “The Cathedral and the Bazar”,
http://catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/
日本語訳としては、山形氏の「伽藍とバザール」が以下の URL で参照可能
http://cruel.org/freeware/cathedral.html
[14] “Open Source Security: A Look at the Security Benefits of Source Code Access”,
TruSecure, August 2001.
[15] John Viega, Gary McGraw, “Building Secure Software”, Addison – Wesley, 2002.
[16] Common Criteria, http://commoncriteria.org/
[17] RATS, http://www.securesoftware.com/
[18] ITS4, http://citeseer.nj.nec.com/viega00its.html
Ⅰ- 36
第Ⅰ部 オープンソース・ソフトウェアのセキュリティ確保
[19] Flowfinder, http://www.dwheeler.com/flawfinder/
[20] Splint, http://www.splint.org/
[21] Cqual, http://www.cs.berkeley.edu/~jfoster/cqual/
[22] Sardonix, https://sardonix.org/
[23] Solar Designer, http://www.openwall.com/linux/
[24] StackGuard, http://immunix.org/stackguard.html
[25] Bounds Checking, http://www-ala.doc.ic.ac.uk/~phjk/BoundsChecking.html
[26] Stack Smashing Protector, http://www.trl.ibm.com/projects/security/ssp/
[27] FreeBSD stack integrity path, http://www.lexa.ru/snar/libparanoia/
[28] Libsafe, http://www.research.avayalabs.com/project/libsafe/
[29] National Institute of Standard and Technology, “Procedures for Handling Security
Patches”, April 2002.
[30] JPCERT ホームページ, 「管理者のためのセキュリティ推進室」.
Ⅰ- 37