Linuxカーネル開発プロセスが破壊工作を阻止

Eric S. Raymondが述べた「目玉の数が多ければバグなどものの数ではない」というオープンソースの格言を見事に実証するかのように、 Linuxカーネル2.6の開発ツリーに悪質な「バックドア」コードを仕掛けようとする行為が露見し、ほぼ即座に阻止された。

このコードがカーネルの最終リリースに組み込まれていたら、このLinuxバージョンが動いているマシンがリモートユーザーの意のままになっていた恐れがある。イースターエッグと呼ばれることが多いこの未承認コードは、クローズドソースのプログラムではよく見かけるが、オープンソースの世界ではかなりまれな存在だ。開発者なら、興味本位のコードや悪質なコードを内部機構が隠されたプログラムに忍ばせるのは簡単である。しかし、このLinuxカーネル事件で明らかなとおり、オープンソース開発プロセスはこの種の問題に対するある程度の免疫機構を備えている。

このバックドア挿入事件とそれが露見した過程については、Kerneltrap.orgに詳細な説明がある。

最初に事態に気づいたのはBitMoverのLarry McVoyである（BitMoverのBitKeeper製品はLinus Torvaldsを始めとするLinuxカーネル開発者によって大いに利用されているソフト）。改竄されたのはこのカーネルの公開CVSツリーだけだった。 BitKeeperツリーは被害にあっていない。この悪辣な行為が発覚するきっかけになったのはこの2つのツリーの食い違いだった。

NewsForgeに届いた今朝の電子メールで、Larry McVoyはこの状況を次のように説明している。

カーネルコミュニティへのサービスの一環として、我々は公開マシンを提供している。このマシンでは、BitKeeper、CVS、Subversionの各カーネルツリーを運用している。マシン名はkernel.bkbits.netで、cvs.kernel.orgとsvn.kernel.orgという別名が付いている。侵入されたのはこのマシンだ。
CVSを好む人々のために、BitMoverはBitKeeperからCVSへのゲートウェイを作った。我々はこのゲートウェイを社内のBitMoverマシンで運用し、kernel.bkbits.netを、BKからCVSに変換したファイルのミラーにしている。また、ミラー化が終わった後、念のためにBitMoverデータとkernel.bkbits.netデータに対してちょっとしたリモート比較スクリプトを実行している。このスクリプトは毎晩動いて、問題があればメールを送信する。昨日、問題が生じたことがわかったので、調べた上で、不良版のファイルを保存してから問題を解決し、LKML（ Linuxカーネルメーリングリスト）にメールを送った。
カーネル開発者の一部が述べているとおり、事態に気づいたのは我々が異常なほど慎重だったおかげとしか言いようがない。 BitKeeperユーザーから聞かされた教訓によれば、おかしくなる可能性があるものは必ずおかしくなるので、アプリケーションには安全性チェックが不可欠だ。今回はCVSゲートウェイで同じことをして成功した。
また、BitKeeperの設計を考えると、この種の侵害がBitKeeperでうまくいくことはまずない、とLinus自身が指摘していることも書き添えておくべきだろう。

数分後、Linus Torvaldsから次のようなメールが届いた。

このようなことをする輩がいるのにはいつもあきれるが、それを除けば大したことがなくてよかった。ただ個人的には、「ちょっとした騒動」から「極めて深刻な事態」までをひっくるめて、このようなハッキング行為を「興味深い」と思わないでもない。
プロジェクトのCVSツリーにバックドアが仕込まれると、理論上、非常に深刻な事態を招きかねなかったわけで、その意味ではすべて「きちんと」処理された。コードは無害に思えるようになったし、CVSの履歴も見たところは正常なようだ。コアCVSツリーにこのようなものが紛れ込むと、発見するのはまず不可能に近い。 500万行の中に紛れ込んだ2行のコードは、突き指でヒリヒリする親指ほど気づきやすくはないからね。
まあ、ほかのプロジェクトの多くとは違い、 Linuxカーネル開発では実際にはコアCVSツリーはまったく使われていない。このCVSツリーは、CVSを使いたい人々のために自動生成された読み取り専用エクスポートにすぎない。そういう意味では、バックドアが「現実」のツリーに紛れ込むことはあり得なかった。本物のツリーは公開されていないし、これまで公開されたこともない。
おかげで被害を被らずに済んだし、CVSツリーが再生成されたときに事態が発覚したわけだ。誰かがバックドアを組み込もうとしたのは深刻な事態だと思うので、そういう意味では我々がこの問題を真剣に受け止めたのは確かだ。ただ、皆さんにもわかるだろうが、技術的には大した問題ではない。
今回の事態に使われたことが判明しているマシンの所有者とも話してみるつもりだが、かなりルーズな環境にある大学のマシンだった。今頃はすでに非常線が張られて、マシンは監視下にあるだろう。

オペレーティングシステムやコンパイラなどの低レベルプログラムに悪質な機能を組み込む（または組み込もうとする）コード作成者の問題は決して新しいものではない。 Unixの原作者Ken Thompsonは、 C言語コンパイラにトロイの木馬が組み込まれる可能性について1984年にReflections on Trusting Trustという記事で言及している。この記事には次のように書かれている。

すべてを自分で記述したものではないコードを信用してはいけない（私のような人間を雇う会社のコードは特にそうだ）。ソースレベルの検証や監視をどれだけ強化しても、信用できないコードを使ってしまう危険性はなくならない。この種の攻撃が行われる可能性を実証するためにここではCコンパイラを取り上げたが、アセンブラやローダーはもちろん、ハードウェアのマイクロコードに至るまで、どのようなプログラム処理プログラムを取り上げても同じことだ。プログラムのレベルが下がるほど、このようなバグを見つけるのは困難になる。マイクロコードにうまく潜り込んだバグを検出するのはほぼ絶望的だ。

つまり、コード開発プロセスでどれだけセキュリティに気を配ったとしても、常に一定レベルの信頼性を確保しておかなければならない。「ソースレベルの検証や監視をどれだけ強化しても、信用できないコードを使ってしまう危険性はなくならない」というThompsonの指摘は、当時は真実の一部を言い当てたにすぎなかったかもしれないが、今ではこれに勝る警句はない。監査のせいで人間によるコード検証作業が増加したり、今は存在しても80年代には存在しなかったソフトウェアでコード比較を行ったりする場合は特にそうだろう。

この悪質なコード仕掛け人が予想していなかったはずの最新セキュリティテストでは、このLinux開発プロセスには何の問題もなかった。この経験を活かせば、今後、攻撃への抵抗力が強くなるはずである。

プロプライエタリであろうとオープンソースであろうと、 皆さんのコード開発プロセスは同様のテストに合格できるだろうか。