Red HatのMark Cox氏、セキュリティについて語る
Cox氏がセキュリティに関心を持ち始めたのは約12年前、米国立スーパーコンピュータ応用研究所（NCSA：National Center for Supercomputing Applications）のNCSA HTTPdというWebサーバでセキュリティ上の問題を発見したときからだという。「その後すぐに私はヨーロッパでC2Netの活動を立ち上げ、十分なビット長のSSL暗号化を世界中に広めることができるように、特に米国外向けのStronghold Webサーバの開発を進めた。やがてC2NetはRed Hatに買収され、この場に私がいるというわけだ」。Cox氏はRed Hatでのセキュリティ業務に加え、仕事以外の時間をApache Software FoundationのセキュリティチームとOpenSSLグループでの活動に充ててもいる。
セキュリティ対応チームのメンバーには、どんな仕事が課せられるのだろうか。Cox氏によると、こうしたチームは脆弱性の確実な解決に責任を負っているという。「そこには、研究者との連携や我々に悪影響を及ぼす問題の監視と検知、優先順位付けや調査、リリース過程の監視といった数々の仕事が含まれる」
また、セキュリティ対応チームのメンバーには、勧告を作成したり、脆弱性に関する顧客からの質問に答えたりする役目もある、とCox氏は話す。「昨年、我々は問い合わせ対応の98％を1営業日以内に成し遂げた」
Red Hatのような大手ベンダでは厳密にどれほどの人数がセキュリティの問題に携わっているのか、知りたい人もいるだろう。セキュリティに取り組むために何名が直接雇われているかについてCox氏が言及することはなかったものの、多くの場合は脆弱性の種類ごとに技術者を集めている、と彼は語った。
「Red Hatには世界各地の時間帯をカバーするために常勤の技術者が数多くいるが、より優れた人材を常に探し求めている。問題に対処するときには、開発や品質工学のチームからも特定の領域の専門知識を採り入れることになる。そのため、セキュリティの脆弱性に関わるRed Hat社員の数は毎週変わる」（Cox氏）
多くの場合、セキュリティチームは脆弱性に関する情報を一般の人々よりも早く入手する。実際のところ、Red Hatのセキュリティチームの場合は「その確率は五分五分くらいだ」とCox氏は言う。つまり、Red Hatには広く一般に知れ渡る前に脆弱性を解決できる時間的余裕が大抵あるわけだ。「前もって問題がわかっている場合は、同業他社との連携による適切なパッチの入手、類似したコードベースに同様の問題がないかの調査、念入りなテスト、影響を被る他のディストリビュータとのリリース調整といったことが可能になる」
しかし、たとえまだ公に知られていない脆弱性の問題であってもできるだけ早期の解決を試みている、とCox氏は言う。「実際、ここ2年間について見ると、我々が事前に把握した脆弱性の情報が世間に広まるまでの日数の中央値はわずか7日だった。危険性の高い一部の問題に限れば、その中央値は2日に縮まる」
脆弱性はどこから判明するのか
セキュリティの脆弱性の多くはどのようにして発見されるのだろうか。Cox氏は自身のブログで、2005年3月から2007年3月までの期間にRed Hatが得た脆弱性の情報の発信元を分析している。そこには、そうした脆弱性の情報が、公になる前にRed Hatに届いたかどうかも記されている。
Cox氏の分析によると、情報の発信元として一番多いのが他のFLOSSベンダであり、次に多いのがFirefoxのような上流にいるベンダからの報告だという。また、Red Hatでは世間に知れ渡る前にそうした情報を他のFLOSSベンダや上流プロジェクトから得ていることが多い。
ところで、そうした情報の発信者は、そもそもどのようにして脆弱性の問題を見つけ出すのだろうか。Cox氏によれば、その方法はいくつもあり、積極的な監視によって見つかることもあれば、他の問題に関するバグレポートからわかることもあるという。「上流に位置するプロジェクトやディストリビュータがときどき監査やコード解析ツールの実行を行っているほか、セキュリティに関する新手法によって問題が事前にわかったり、顧客のバグレポートからセキュリティに関わる因果関係が明らかになったりする場合もある」
問題の発生を食い止める
問題が起こってから修正するというのでは、発生した火災を鎮めるのと基本的に同じで、計画になっていない、とCox氏は語る。そのため、Red Hatや他のLinuxベンダでは、セキュリティ問題の影響を緩和するテクノロジに取り組んでいる。例えば、SELinuxやExec-Shieldは特定の種類のエクスプロイト・コードを阻止することにより、システムを保護することができる。
この4月にCox氏は、脆弱性を緩和するテクノロジについて記した解説記事を公表した。その中で彼は、Red Hat Enterprise Linux（RHEL） 3および4に備わっている様々なセキュリティ機能とそれらによって対処できるエクスプロイトの種類について述べている。
例えば、2つの「ダブルフリー」脆弱性が説明されている。ダブルフリーとは、1つのメモリアドレスに対してfree()関数の呼び出しが2回行われる状況である。これはバッファオーバフローにつながる恐れがある。ダブルフリーの脆弱性に対するglibcの「強化」がまだ行われていなかった2003年には、この欠陥が「wu-ftpdやCVS pserverのようなサービスに対する派手な手口の攻撃」の原因になった、と記事には書かれている。
2004年、MITによるKerberos 5のKey Distribution Centerでダブルフリーの欠陥が見つかり、公表された。しかし、この欠陥に対処すべくRHEL 4のglibcが強化されていたため、「ダブルフリーの脆弱性の悪用は完全に回避され、重大としていたこの欠陥の重要度をより低いランクに下げることができた」という。
脆弱性の深刻さはそれぞれに異なる
Red Hatは、脆弱性について通知する際にその深刻さの判定も合わせて公表している。公表されたセキュリティの問題の一覧には、それぞれの重要度が4段階で示される。その段階には、ユーザとのやりとり一切なしにリモートの攻撃者がシステムに影響を及ぼすことが可能なもの（「重大」）から、セキュリティ面にそれなりの影響力を持つがシステムに対してエクスプロイトを実行するのが非常に困難か、エクスプロイトの影響力がわずかと判断されるもの（重要度が「低」）まである。
Red Hatでは、実際に利用可能なエクスプロイト・コードが世間に存在するかどうかによってセキュリティ重要度の分類を変えてはいない。そこには、脆弱性についての報告を行う他の組織と歩調を合わせるという狙いもある、とCox氏は言う。「ユーザにとってのリスクは、脆弱性と危険性、両者の関数として定義される。一方、我々の勧告に記される判定は、脆弱性だけに基づいており、MicrosoftやApacheのような他のベンダの判定に一致するように行われる。危険性の度合いは時間が経つにつれて変化し、エンドユーザ側の設定や使用法に大きく依存するため、我々はその部分については言及していない」
Linuxを狙ったエクスプロイトは増えているか
数年前は、Linuxの普及が進むにつれてLinuxを対象として作られるエクスプロイト・コードがますます増えるだろう、というのが一般的な認識だった。Red Hatではリリース後の2年間でRHEL 4に影響を与え得たエクスプロイトの調査を終えたばかりだが、どうやらこの認識は外れていたようだ。「37の脆弱性を対象とした各種エクスプロイトの存在が明らかになっている。その多くはセキュリティ関連のさまざまな新手法によって捕捉され、なかにはありそうもない設定を必要とするものもあるため、大半は世間で言われているほど機能していない。あと残っているのは、パッチの当たっていないマシン上でローカルユーザによるルート権限の取得を可能にするいくつかのカーネルエクスプロイト、そしてパッチの当たっていないWebブラウザに対して作用するエクスプロイトだ」
「Webブラウザの欠陥を別にすると、最近は攻撃者がエクスプロイト・コードを書けるようなリモートの脆弱性がそれほど多くない、というのが実状だ。例えば、Enterprise Linux 4 ASのデフォルトインストール環境の場合、攻撃にされされた重大なセキュリティの問題がリリース後2年で3件しかなかった」
