今回のコラムでは，9月から10月にかけて，セキュリティ関連のメーリング・リスト「BugTraq」において，活発な議論が展開された，「traceroute」のセキュリティ・ホールを考察する。tracerouteとは，UNIX系OSのネットワーク・ツールである。IPパケットがどのような経路（ルート）を通って，目的ホストにたどりつくのかを調査するために利用する。TCP/IPを勉強してみようと思った人なら，一度は試したことがあるだろう。
このセキュリティ・ホールは，ローカル・ユーザーがroot権限（管理者権限）を取得できる可能性があるというものである。リモートからは攻撃できないので，危険度はそれほど大きくない。しかしながら，そのメカニズムが興味深い。メモリー管理のプログラム・バグが原因のセキュリティ・ホールであるが，「バッファ・オーバーフロー」や，前回の私のコラムで紹介したセキュリティ・ホールとは異なり，他にあまり例がない。
Bugtraqでは，「Very interesting traceroute flaw（とても興味深い，tracerouteの弱点）」というメールの件名（Subject）で議論されていた。とはいっても，サーバー管理者にとっては，“興味深い”とばかり言ってはいられない。パッチを適用するなどして，対策を施す必要がある。
あるパラメータを指定すると
tracerouteがクラッシュ
今回のセキュリティ・ホールは，あるパラメータ（引数）を指定してtracerouteを実行すると，tracerouteがクラッシュしてしまうというものである。さらに，マシンのroot権限を取得される可能性がある。
セキュリティ・ホールが確認されているのは，tracerouteプログラムの1つであるLBNL (*1) tracerouteの特定バージョン。RetHat 6.1/6.2，Debian 2.2，Vine 2.0などのLinuxディストリビューションに含まれている。各ディストリビュータからは，既にパッチが提供されている。
原因はメモリー管理のプログラム・ミス
それでは，なぜ，あるパラメータを指定するだけでクラッシュしてしまうのか，なぜ，root権限を奪われてしまうのだろうか。問題は，tracerouteが複数のゲートウエイ・パラメータ（-g）で起動された時の，メモリー管理の仕様にある。ゲートウエイ・パラメータとは，複数の経路がある場合に，経由するゲートウエイ（マシン）を明示的に指定するオプションである。
C言語では，メモリー領域の確保と解放には，それぞれ「malloc関数」と「free関数」を利用する。C言語を多少かじったことがある人ならば，ご存知だろう。今回のセキュリティ・ホールは，メモリー管理のための関数--すなわち，malloc関数とfree関数--の使い方に問題があった。
一般のプログラム同様，tracerouteでも，ゲートウエイ・パラメータの次に入力した文字列（通常は，ゲートウエイのIPアドレスやホスト名）を記憶するために，malloc関数とfree関数を使用する。実際には，tracerouteの内部関数である「savestr関数」がmallocとfreeを使用している。このsavestr関数に問題があった。適切なメモリー管理には，メモリーの確保（malloc）とメモリーの解放（free）が正しく“対”で使用されなければならない。しかし，traceroute（正確にはsavestr関数）では，ゲートウエイ・パラメータを2回指定すると，この“対”が崩れてしまう。
savestr関数は，1つめのゲートウエイ・パラメータのために，malloc関数でメモリーを確保して，パラメータで指定された文字列を記憶する。そして，free関数を呼ぶことなく，再びmalloc関数を呼んで，2つめの文字列を記憶し，free関数を呼び，処理は終了する。すなわち，1回目はメモリーの確保だけして解放せず，2回目のメモリー確保と解放を行っている。ここで“対”が崩れ，メモリー管理が失敗する。そのため，2つめのメモリー領域が，1つめのメモリー領域を上書きしてしまう恐れがある。
malloc関数は，実データ（ここではゲートウエイ・パラメータの値）のためのメモリー領域に加えて，確保したメモリー領域の情報を管理するための領域を確保する。この「メモリー管理のためのメモリー領域」は，「chunk」と呼ばれる場合がある。今回の問題を突けば，このchunkテーブル情報を，ユーザーが入力した実データで上書きできる。この実データ部分を注意深く作成すれば，メモリー管理をユーザーがコントロールできてしまい，tracerouteを単にクラッシュさせるだけではなく，任意のコマンドを実行させたり，root権限を奪える可能性がある。
メモリー管理の領域を，ユーザーが入力したデータで上書きして，プログラムの処理制御を不正に取得する点では，バッファ・オーバーフロー攻撃と類似している。しかしながら，今回のセキュリティ・ホールを突く攻撃は，今までに発見されたバッファ・オーバーフロー攻撃とは異なる。そのため，「offset free 攻撃」という名称を付けて区別したい。
以上の説明は，分かりやすさを優先させたので，厳密性に欠ける部分は多い。実際はもっと複雑である。「offset free 攻撃」を詳しく知りたい方は，「SecurityFocus」や「LWN.net」などのWebサイトを参照してほしい。
管理者の怠慢は許されない
今回のようなバグは，どのようなツールにも潜んでいる可能性がある。ファイアウオールやIDS（Intrusion Detection System）といった，不正アクセス対策ツールにも潜んでいる可能性はある。潜在的な危険性は高い。セキュリティ・ホールは発見され次第，即対応しなければならないものであることを認識しなければならない。ソフトウエアのセキュリティ・ホール情報などを公開している米国の機関「CERT/CC（the CERT Coordination Center）」や「コンピュータ緊急対応センター（JPCERT/CC）」などが助けとなるだろう。
しかしながら，こういった機関が再三警告を発しているにもかかわらず，同じセキュリティ・ホールを使用する攻撃が後を絶たない。これは，サイトを運営している管理者の，単なる怠慢によるものだ。警告はできても，それ以上のことは第三者にはできない。管理者がやらなければならないことなのだ。
「管理者のみなさんは，情報収集を行い，適切にパッチを適用しましょう」という，何度も繰り返されているせりふしか言えない自分がもどかしい。
後を絶たないFTPサーバーのセキュリティ・ホール
前回私は，FTPサーバー「wu-ftpd」に関するコラムを書いた。その後，CERT/CCから再びwu-ftpdに対する警告が発表されたので，フォローしておきたい。
前回のコラムでは，wu-ftpdのsite execコマンドにおけるセキュリティ・ホールに絞ったが，その他にも対応しなければならないバグが発見されている。「wu-ftpd-2.6.0」を「wu-ftpd-2.6.1」へバージョンアップするだけでは，すべての問題を解決したことにはならない。「wu-ftpd-2.6.1」へバージョンアップした後，パッチを適用する必要がある。
wu-ftpdのバグに関しては，こがよういちろう氏が技術的考察を公開されているので，そちらを参照してほしい。
同氏も言及されているが，今後の進歩が見込めそうにないwu-ftpdを，別のFTPサーバーに変更するのも1つの選択肢である。参考までに，他のFTPサーバーを1つ紹介するならば，「ProFTPD（最新バージョンはproftpd 1.2.0rc2）」が挙げられる。ProFTPDは，wu-ftpdより歴史は新しいが，セキュリティを考慮して開発されている（もちろん，セキュリティを考慮したプログラムといってもバグが出ない保証はない）。その分，処理は多少重い。この欠点は，開発者がWebサイトでも公表している。
しかし，セキュリティと将来性（すなわち，ソース・コードの改良）を考慮するならば，ProFTPDを選択することはお勧めだ。
*1 LBNL：Lawrence Berkeley National Laboratoryの略。
【参考URL】
■LBNL Traceroute Heap Corruption Vulnerability
http://www.securityfocus.com/bid/1739
http://lwn.net/daily/traceroute-bug.php3
■ProFTPD
http://www.proftpd.net/
ftp://ftp.proftpd.net/pub/proftpd/
足利 俊樹（Ashikaga Toshiki）
株式会社ラック 不正アクセス対策事業本部
ashikaga@lac.co.jp
IT Proセキュリティ・サイトが提供する「今週のSecurity Check [一般編]」は，その週に起きたUNIX関連およびセキュリティ全般のニュースや動向をまとめた週刊コラムです。セキュリティ・ベンダーである「株式会社ラック」のスタッフの方を執筆陣に迎え，専門家の立場から解説していただきます。
