3月3日に見つかったsendmailのセキュリティ・ホール。あなたの組織では既に対応済みだろうか。まだの組織はすぐに対応する必要がある。現時点では，セキュリティ・ホールを悪用するワームが出現する可能性はそれほど高くないものの，特定環境のsendmailサーバーの“乗っ取り”が可能であることを示す検証用コードは既に存在する。攻撃自体は現時点でも可能なのである。今後，多くの環境に“通用”するワームが出現する可能性は否定できない。
そのようなワームが出現する前に，すべてのsendmailでセキュリティ・ホールをふさいでおかなければならない。ほとんどのベンダーはパッチを公開している。メール・サーバーをほとんど停止することなくセキュリティ・ホールをふさげるので，一刻も早く適用してほしい。攻撃を受けてからでは遅いのである。
この記事では，今回のセキュリティ・ホールが与える影響や，セキュリティ・ホールの対策方法をまとめた。IT Proでも今回のセキュリティ・ホールに関する記事は何度か掲載しているので，「またか」と思う読者もいるだろう（関連記事1，関連記事2）。実際，過去の記事の内容に重複する部分も少なくない。しかし，今回のセキュリティ・ホールが及ぼす影響を考慮すると，いくら注意を呼びかけても「呼びかけすぎ」にはならないだろう。
もちろん必要以上にあわてる必要はない。“通常の”セキュリティ・ホールと同様に，「パッチの適用」といった通常の対応を施せば十分である。あわてさせることがこの記事の狙いではない。sendmailのユーザー全員に今回のセキュリティ・ホールを知ってもらい，“通常の”対応をきちんとしてもらうことが狙いなのである。
イントラネット内のsendmailも影響を受ける
今回のセキュリティ・ホールは，メール・サーバーのなかで最も利用されているsendmailが対象であり，ほとんどすべてのバージョンが影響を受ける。オープンソースの「sendmail」に限らず，sendmailをベースにしているすべてのメール・サーバー（例えば「Sendmail Pro」）が影響を受ける。sendmailを内部的に使用しているソフトウエアも影響を受ける可能性がある。
さらに今回のセキュリティ・ホールは，sendmailサーバーに対して，細工を施したメールを送信するだけで悪用できる。具体的には，sendmailサーバーへSMTP接続して，ある特定の文字列を送信すれば，バッファ・オーバーフローを引き起こせる。メール・サーバーのポート（通常はTCPポート25番）を閉じれば攻撃を受けることはないが，通常のメールも受け取れなくなる。つまり，ファイアウオールなどで攻撃を防ぐことは難しい。
加えて，攻撃者が直接アクセスできない，イントラネット内で稼働するsendmailサーバーも影響を受ける。インターネットからアクセス可能なメール・サーバーがsendmail以外である場合には，細工が施されたメールを送られても当然影響を受けない。しかし，そのメール・サーバーがそのメールをsendmailサーバーへ中継すると，そのメールを受け取ったsendmailサーバーが影響を受けることになる。
例えば，攻撃メールにバックドアを開くようなコードが含まれていたとする。実行されると，ある特定のIPアドレスのTCPポート80番に向けて通信を開始し，そのIPアドレスからコードが実行されたマシンの操作を可能にするコードだとする。この攻撃メールがまずsendmail以外のメール・サーバーに送られたとする。もちろんそのメール・サーバー上ではバッファ・オーバーフローが発生しないので，そのコードは動作しない。
しかし，そのメールが中継されてsendmailサーバーに到達すると，バッファ・オーバーフローが発生し，そのコードが動き始め，外部とのコネクションを確立する。このコネクションは，TCPポート80番への外向きの通信から始まっているので，Webアクセスを許可している組織のファイアウオールでは遮断できない。つまり，組織内のマシンにバックドアが開かれて，攻撃者は組織内のネットワークを荒らし回れることになる。
攻撃メールに仕込まれたコードが，ネットワーク経由で自分自身を繁殖させるコードである場合，すなわち「ワーム」であった場合，sendmailが稼働しているマシンの数を考えれば，被害は先日の「SQL Slammer」ワームによるものの“比”ではない。1988年に出現した「Morris Worm」以上の被害を招く恐れもある。
セキュリティ・ホールを検証するコードは公開
以上のように，今回のセキュリティ・ホールはとても深刻なのである。とはいえ，現状ではワームが出現する可能性はそれほど大きくはないようだ。というのも，「ハードウエアやOS，sendmailのバージョン――といったsendmailサーバーの環境によって，攻撃方法（攻撃用のコード）を変える必要がある」（ラック SNS事業本部 テクニカルコンサル部の田野広季氏）からだ。今回のセキュリティ・ホールについては，多くのsendmailサーバーに“通用する”ワームやクラッキング・ツールを作るのは難しいようだ。
ただ，“汎用的な”ワームを作ることが難しくても，ある特定環境のsendmailサーバーを攻撃することは現状でも不可能ではない。実際，ある環境のsendmailを乗っ取るようなコードは公開されている。「LSD（The Last Stage of Delirium Research Group）」というグループが，「Slackware 8.0＋sendmail 8.11.6」に，ある古いパッチを適用した環境のsendmailサーバーを乗っ取れるコードを，検証用コードとしてメーリング・リスト「Bugtraq」に投稿している。
このコードを実行すれば，指定したIPアドレスのサーバーへバッファ・オーバーフローを引き起こすようなメールを送信し，そのサーバー上でバックドアを動かして，バックドアとの通信が可能になる。通信が確立すれば，そのサーバー上でroot権限（管理車権限）でさまざまなコマンドを実行できるようになる。
「『バッファ・オーバーフローのセキュリティ・ホール』と一口に言っても，任意のコードを実行できないものもある。理論上任意のコードを実行できるものでも，検証用のコードが公開されていないものもある。今回のセキュリティ・ホールについては検証用のコードが公開されている。これに手を加えることで，別の環境に利用可能なコードを作ることも可能である。“汎用的な”ワームを作ることが難しいとしても，十分危険なセキュリティ・ホールである」（ラック 田野氏）
さらに，「現状ではワームを作ることが難しくても，未知の方法でワームが作られる可能性はある」（同氏）。ワームが作られ，世の中にばらまかれたときの影響を考えれば，たとえ現状ではその可能性がほとんどないとしても，早急に対応すべきセキュリティ・ホールであることは分かってもらえるだろう。加えて，あなたの環境をピンポイントで狙うワームやクラッキング・ツールは，現状でも出現しうるのである。
前述のLSDは，検証用のコードとともに，今回のセキュリティ・ホールの解析レポートを投稿している。その中で，「（LSDが考えたシナリオで悪用する場合）今回のセキュリティ・ホールの影響は比較的限定される。しかしながら，現在考えている以外の方法で任意のコードを実行させられる可能性はある」といったことを書いている。
それを受けて，sendmailの開発者であるEric Allman氏は，上記カッコ内の2文目（「しかしながら，～」）を強調し，「今回のセキュリティ・ホールを悪用することが困難であるとしても，多分不可能ではない。すべてのsendmailユーザーはできるだけ早くパッチを適用する必要がある」と投稿している。
どのようなセキュリティ・ホールでも，自分がそのソフトウエアを使用している場合には当然放置してはいけない。対策は不可欠である。しかし，今回のセキュリティ・ホールについては，特に対策が急務なセキュリティ・ホールなのである。
まずはパッチの適用を
今回のセキュリティ・ホール対策としては，
- パッチを適用する
- 最新版 8.12.8 にバージョン・アップする
- sendmail以外のメール・サーバーに乗り換える
が挙げられる。しかし，この中でまず管理者が実施すべきは「現在使用しているバージョンにパッチを適用する」（NECソフト サーバーソリューション事業部 Linuxソリューショングループ 主任の淡路修一氏）ことである。
「バージョンを上げるとなると，現在のバージョンとの機能や設定の違いを調べたりするのに時間がかかる。別のメール・サーバーに乗り換えるとなると，なおさらである。今回のようにすぐに対応しなければならないセキュリティ・ホールについては，まずはパッチで対応する」（NECソフト 淡路氏）
今回のセキュリティ・ホールを機会に現在のメール・システムを見直して，別のメール・サーバーへ移行したいと考える組織もあるだろうが，「その話とは別に，まずは現在使用しているバージョンでセキュリティ・ホールをふさぐべきである。その後に，（メール・サーバーの移行などは）時間をかけて考えるべきことである」（同氏）
現在使用しているバージョンにパッチを適用するだけなら，メール・サーバーはほとんど停止させる必要はない。各ベンダーが提供している修正版バイナリやパッケージをダウンロードして，バイナリの置き換えやパッケージの適用後，sendmailを再起動するだけでよい。各ベンダーの対応状況は，「Vendor Status Note JVNCA-2003-07」に詳しい。同ページからリンクが張られている各ベンダーのページのほとんどに，パッチの適用方法が具体的に書かれている。
例えば，セキュリティ・ホールを修正したバイナリを用意しているHP-UXやFreeBSDなどでは，バイナリ（sendmail）を入れ替えて，sendmailを再起動するだけでよい。rpmやdebといったパッケージを用意しているRed HatやDebianなどでは，それらのパッケージを「rpm」コマンドや「apt-get」コマンドで適用した後，sendmailを再起動すればよい。Windows版Sendmailも同様である（関連記事）。
パッチなしのバージョンではできるだけ“近い”バージョンに
オープンソース版のsendmailでも同様である。パッチがソースで提供されているので，バイナリやパッケージが用意されている場合に比べれば手間はかかるものの，サーバーを止める必要はほとんどない。
現在使用しているバージョンのsendmailのソースに，対応するパッチを適用し，ビルド（make）してインストール（make install）すればよい。ただし，このとき注意しなければならないのは，「sendmail.cfなどの設定ファイルのバックアップを取っておく」（NECソフト 淡路氏）こと。修正版のインストールで，苦労して作ったsendmail.cfが上書きされてしまう恐れがあるからだ。
インストール後，sendmailを再起動すれば，セキュリティ・ホールが修正されたsendmailプロセスが動きだすことになる。パッチが適用されたかどうかの確認方法はsendmail.orgのページにあるように，
strings sendmail | grep 'Dropped invalid comments from header address'
と実行することである。修正されたsendmailの中には，今までのsendmailには含まれていなかった「Dropped invalid comments from header address」という文字列が追加されている。上記コマンドの実行で，この文字列が表示されれば，きちんとパッチが適用されていることになる。
では，パッチが公開されていないバージョン（sendmail 8.8以前）を使用している場合にはどうすればよいか。とにかくバージョン・アップしなくては対応できない。この場合，最新版8.12.8にすべきか，パッチが用意されている最も“近い（古い）”バージョンにすべきか。NECソフトの淡路氏によると，「できるだけ“近い”バージョン，すなわちsendmail 8.9にすべきだ」という。
理由の一つが，「現在使っているバージョンと機能の差が小さいほうが，混乱することなく迅速に移行できる」ということ。もう一つが，「CFはsendmail 8.9をサポートしているが，それ以降はサポートしていない」ことである。「CF」とは，WIDEプロジェクトが公開する，sendmailの設定ファイル「sendmail.cf」を作成するためのツールである。「sendmail 8.8を使用しているユーザーは，CFを使用している可能性が高い。バージョン 8.10以降では，標準添付のm4マクロを使ってsendmail.cfを作る必要がある。経験がないユーザーでは，m4マクロの使い方を調べるだけで時間がかかるかもしれない」（同氏）
前述のように，今回のセキュリティ・ホールはできるだけ早く修正しなくてはならない。「セキュリティ・ホールをふさぐついでに，最新版にバージョン・アップする」あるいは「別のメール・サーバーに乗り換える」といったことを考えていると，いつまで経ってもセキュリティ・ホールをふさげない恐れがある。まずは，セキュリティ・ホールをふさぐことだけを考える。繰り返しになるが，最新版や別のメール・サーバーへの移行はその後じっくり考えればよい。
また，パッチを適用することだけがセキュリティ・ホール対策ではない。不要なsendmailサービスを動かさないことも当然対策の一つである。特にイントラネット内には，管理者が把握していない，sendmailが稼働しているマシンが存在する可能性がある。今回のようなセキュリティ・ホールに対しては，たとえイントラネットの中でも，稼働しているだけで危険なのである。今回のセキュリティ・ホールを機会に，そういったマシンを洗い出して，不要なsendmailサービスを停止させたい。
もちろん，sendmailに限らず，不要なサービスはすべて停止しておくべきである。不要なサービスを稼働させておいても何もよいことはない。セキュリティ上のリスクを高めるだけである。
◎参考資料
◆CERT Advisory CA-2003-07 Remote Buffer Overflow in Sendmail（米CERT/CC）
◆Remote Sendmail Header Processing Vulnerability（米ISS）
◆Sendmail Security Alert（米Sendmail.org）
◆Remote Sendmail Header Processing Vulnerability（米NIPC）
◆Sendmail における深刻なセキュリティ脆弱性について（IPA/ISEC）
◆sendmail の脆弱性に関する注意喚起（JPCERT/CC）
◆Sendmailのヘッダー処理に対する脆弱性（インターネット セキュリティ システムズ）
（勝村 幸博＝IT Pro）
