セキュリティのつぼ（1）

セキュリティホールはなぜできる？

橋本　晋之介
2001/11/10

本連載では、セキュリティ技術や周辺テクノロジといった技術論だけではなく、セキュリティ導入を検討するために知っておくとちょっとためになるテーマを順次掲載する。技術者、コンサルタント、ユーザーの方々への参考としてほしい。（編集局）

●セキュリティホールとは何か

　ここ数年、セキュリティホールという言葉をよく聞くようになった。そのセキュリティホールが悪用された結果システムに侵入されたり、ウイルス感染のきっかけになるということはよく知られている。だが、セキュリティホールが何かということはあまり知られていないようだ。

　セキュリティホールとはシステムの安全面における"穴"のことだ。

　遊園地の金網に穴が開いていて、そこからタダで入られてしまうようなものだ。もちろん、コンピュータシステムの話だから目に見える形で穴が開いているわけではないが、概念は似ているのでホールといわれている。

　セキュリティホールはシステム開発者が作ってしまう。一般には意図して作られるものではないが、中には開発者が意図的に作っているものもある。その理由はさまざまだが、開発者自身の利便性を狙ったものが多い。例えば、「デバッグのための情報を入手したい」とか、「システムの運用状況を知りたい」といった理由だ。開発者はその秘密の入り口を内緒にしていれば大丈夫だと思うようだが、クラッカーたちは巧みに調べ上げてしまう。これはコンピュータゲームの裏技を探すようなもので、クラッカーの楽しみの1つなのだ。こんなことはちょっと人生経験を積めば簡単に想像できる。つまり、秘密の入り口を作ってしまう開発者はそれだけ意識レベルが低いのだ（ちょっとキツイいい方ですかね）。

　とはいえ、ほとんどのセキュリティホールは設計や制作時のミスによって作られてしまう。ここでその主な原因を紹介しよう。

●ソフトウェア開発は工場制手工業

　産業が発達し、大量生産・品質均等が当たり前となっている今日、その産業のけん引役にならねばならないIT産業は悲惨な状況にある。特にソフトウェア産業は極めて能率が悪い。たぶん、「工場制手工業」^＊1といってもいい過ぎではないだろう。

　実は、ソフトウェアやコンピュータシステムは人間の頭脳だけで作り上げるには大規模で複雑すぎるのだ。

　ところが、そのような大規模な仕組みを考えたり、設計を確かめる手法が工学的に確立されていない。もう、20年以上も前から危機が叫ばれているが、有効な解決策はまだ生まれていない。

　そのため、システム開発は熟練プログラマーやシステムエンジニアが経験と勘を頼りに組み上げている。そのうえ、ソフトウェアの開発技術は組織に蓄積されにくい。技術はプログラマーやシステムエンジニアに蓄積される。このため、同じようなシステムでも開発者の熟練度が性能の差となって表れるのだ。

　システム開発時にはチームを組み、数人から数千人のプログラマーがシステムの機能や構成ごとに分担して開発する。数人のチームならば優秀なプログラマーを集めることも可能だが、数十人のチームとなるとどうしても数人は優秀とはいい難いメンバーが含まれてしまう。ましてや、数千人ものチームを組むとなると……。

　システムの安全性や安定性は、開発チームの中の最もスキルの低い人物によって決定される。その人物の作ったものを優秀なメンバーがチェックできればいいのだが、それができるくらいなら最初からその優秀な人物にすべて任せた方がいいだろう。会社にはそれができない理由があるからチームを組み、能力が劣る人物を加えざるを得ないのだ。

＊1　問屋や大商人が、多くの職人を集めて､手分けして仕事をさせる生産の仕組み。マニュファクチュアともいう。

●機能の増大がシステムを複雑にする

　システムは大きくなる宿命を負っている。ユーザーがそれを望むこともあるし、自由経済では機能の増大を競争の道具とすることもある。特に、最近のように不景気が長引くと何が何でも売り込まねばならない。ライバル製品にない機能を追加してアピールすることが重要になる。

　開発者は「だれも使わないだろう」と思う機能も作らねばならない。

　すると、システムはますます複雑になり、その全体を把握することが難しくなる。その結果、開発チームのメンバーのだれも注意していない部分や、メンバー間で意思の疎通が不十分な部分にバグやセキュリティホールができることになる。

　さらに、機能の増大は作業の増大になる。10％機能が増えれば作業時間はたいてい25％は増えるだろう。追加する機能部分だけを作ればよいのではなく、その機能を追加するために既存の部分も改造しなければならないからだ。また、全体で整合性を取らねばならない。だが、作業量は増えても開発期間は増えないのが自由経済のつらい面である。特に、市販ソフトウェではライバル製品の開発・販売スケジュールを見越して、自社製品の開発を早めることがある。こうなると、開発工程では熟慮できずに見落としや思い込みが起きる。それが機能不全のバグになるならまだいい（本当は良くないが）。セキュリティホールになることがあるから恐ろしいのだ。

　また、追加された機能を「だれも使わない」という思いが開発に悪影響を与えることがある。開発者は人間であるし、それを補助する有効な仕組みがない。すると、気乗りのしない仕事では思慮が浅くなり、後で述べるテストも甘くなる。開発期限が迫ればほかの部分に気を取られやすい。思わぬセキュリティホールができやすいのだ。

●担当者の交代も問題点の1つ

　IT産業は人材の流動が激しい。転職が当たり前のこの業界では同じシステムでもバージョンが異なると開発者が違うことが珍しくない。システム開発中に担当者が異動してしまうこともよくあることだ。

　上記のように、システム開発は個人の能力によるところが大きい。担当者が変われば考え方も作り方も変わってくる。だが、システムは継続して開発しなければならない。そこで、前任者が制作した部分を後任者が理解しなければならない。

　ところが、ソフトウェアのソースプログラムも電子回路図も人間には正確に読み取ることが難しい。そのためにコメントを記述して理解を助けるのだが、そのコメントは開発者自身が記入するものだ。本来第三者が読んで分かるように書くことが基本だが、たいていは自分のためのメモ程度にしかコメントを書かない。

　後任者が前任者の意図を理解する助けにならないことが多いのだ。

　当然誤解が生じる。誤解によってシステムが動作しないとか、誤動作する程度ならまだいい（本当は良くない）が、セキュリティホールになってしまうこともある。

●ソフトウェアの完璧なテストはほとんど不可能

　出来上がったシステムや部品は動作を確認する。これをテストという。

　テストはあらゆるパターンを想定してすべてを確認するのが理想だが、ちょっとした規模のシステムではこれは不可能だ。

　なぜなら、入力する値のパターンだけでも膨大な数になる。その数は天文学的な数値をはるかに超え、「情報工学的な数値」というほどの数値だ。

　仮に、64bitsの全数値についてテストするとしよう。入力パターンは2の64乗通り。これはおよそ1.8×10の19乗通りである。1万通りのパターンのテストがわずか1秒で終わったとしても、全パターンのテストには1.8×10の15乗秒≒6000万年かかる。

　さらに、システムは状態機械と呼ばれるものが多い。これは内部に「状態」というものを持っていて、その状態によって同じ入力があっても動作が異なる。すると、テストすべきパターンは入力パターン数に状態数を乗じたものとなる。つまり、単純なテストでも天文学的な時間がかかるのに、さらにその数十乗もの時間をかけなければ理想的なテストができないのだ。

　このため、テストは十分に行われていない。一般には、理想的な入力パターンを想定して、そのときの動作確認をしているにすぎない。例えば、氏名入力欄では一般的な名前を入力しているだろう。そこに、「中国語や韓国語で入力したらどうなるか」とか、「南米のように数百字もある正式な氏名を入力したらどうなるか」などはテストされないことが多い。

　こういった想定外の入力に対しては、あらかじめシステムがエラーメッセージなどを出すように作るべきだ。そして、エラーメッセージが正しく表示されることを確認すべきだ。だが、どのような入力がされるかを想定することは難しい。それはプログラマーやシステムエンジニアの人生経験からも影響を受ける。若いプログラマーがセキュリティホールを作ることが多いのは、人生で辛酸をなめた経験が少ないためかもしれない。

●思わぬ使い方がセキュリティホールになる

　システムに対してどのような入力があるかを想定することは難しい。

　そのことを利用してクラッカーたちはハチャメチャな入力を繰り返してシステムを混乱させるということをよく行う。また、先に挙げた氏名の例のように、正規の利用方法だがあまり一般的ではない入力を行う例もある。そのようなときにシステムが正しくエラー処理を行えるかどうかが問題になる。

　セキュリティホールの代表であるバッファオーバーフローは、長大な入力によってバッファ^＊2があふれてしまい、これを悪用してプログラムを乗っ取る手口につながる。

　以前は悪意を持ってバッファをオーバーフローさせるようなことはなかったので、バッファがあふれないように監視する仕組みを作ったり、あふれた場合の対処法などが考慮されてなかった。バッファの大きさは経験的に十分なサイズを用意すれば事が足りていたのだ。現在ではバッファの管理はシステムの義務になっている。

　しかし、このような仕組みはシステム本来の機能とは別のものである。このため、注意が不十分だと見落としが起きることがある。最近になってもバッファオーバーフローのセキュリティホールが報告されるのは、この見落としのためであろう。

＊2　一時的な記憶領域。通信など動作速度の異なる装置間に用意され、一時的にデータを蓄えておくために利用される。

●私なりのソフトウェアを選ぶ基準

　システムを乗っ取ったり、ウイルス感染に利用するという悪用は、システム開発者の想定していない使い方である。従って、どこにセキュリティホールができてしまうかは分からない。バッファオーバーフローのように、よくあるセキュリティホールについてはある程度注意されるが、それでも見落としが起きることがある。

　根本的な対策にはシステム開発手法の工学的な確立が必要だ。だが、それにはまだ相当な時間がかかる。当面は信頼できる優秀なシステムエンジニアやプログラマーに頼らざるを得ない。また、システム開発時にはなるべく少人数のチームで当たりたい。

　仕事を依頼するのであればそのような体制をとっているソフトハウスやメーカーを選択することが大切だ。そのためにはシステムをよく評価して、開発者のスキルと注意力を推察するしかない。

　それは難しいことなので、次のことに注意してシステムやソフトウェアを選択する目安にするとよいだろう。ただし、これは一般論である。読者自身の人生経験も参考にして自分の責任で選んでほしい。

●毎年のようにバージョンアップを繰り返すシステムは危険

●ライバル製品と同時期に発売している製品は危険

●セキュリティホールが繰り返し報告されるシステムを開発している企業は危険

●新しいシステムは未知の危険がある可能性がある。しばらく様子を見るべきだ

●人材の異動が激しすぎる企業の製品は危険

●不要な機能を多数備えたシステムは避けた方が無難

●Webなどでセキュリティ情報やバグ情報を公開していない企業は信頼できない

●長く使われていて改変のないシステムは比較的安全

Profile

橋本　晋之介（はしもと しんのすけ） 1965年生まれ。長岡技術科学大学大学院修士課程修了（電気電子システム工学専攻）。NEC子会社に勤めた後、1994年（有）ケイワーク（http://www.k-work.co.jp）設立に参加。はじめのうちはなかなか経営が安定しなかったので執筆業に手を染め、現在に至る。熱烈なKawasaki Racing Team のファンで全日本ロードレースや国内で開催されるロードレース世界戦はたいてい観戦している。交通費と応援グッズ購入費が足りなくなり@ITで連載を始めた（爆）。最近では電子出版事業も手がけている。http://www.aswe.jp

Security&Trust記事一覧

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