要約

  • Microsoft は2002年7月に SQL Server 2000 Resolution Service の修正版を公開していたが、CAIDA によれば、翌年1月の Slammer は10分以内に到達可能な脆弱ホストの90％超へ感染した。
  • 問題は一社の権限では閉じなかった。Microsoft はコードを直せても、組み込み MSDE の所在、稼働中プロセスの更新、UDP 1434の到達性、共有回線を守る即時隔離は、それぞれ別の当事者が実行し証明する必要があった。

公開日と実行日は同じではない

Microsoft Security Bulletin MS02-039 の公開日は2002年7月24日である。対象は SQL Server 2000と Microsoft Desktop Engine 2000。複数の名前付きデータベースインスタンスをクライアントが見つけるため、Resolution Service は UDP 1434で問い合わせを受けていた。入力長の確認が不十分な関数へ細工した要求を送ると、スタックバッファーを越えて SQL Server サービスアカウントの権限でコードを動かせた。

Microsoft は警告だけでなく、修正プログラム、確認すべきファイルバージョン、不要な環境では UDP 1434を遮断するという軽減策を示した。10月16日公開の累積修正 MS02-061 にも同じ修正が入った。カレンダー上は半年近い猶予があった。

しかし、公開日はベンダー側の状態しか示さない。Microsoft は修正済みバイナリを作れても、第三者製品が MSDE を導入した全端末を特定できない。各組織の停止時間を決めることも、独立管理されたサービスへ新しいファイルをロードすることもできない。旧プロセスが稼働し、そこまでパケットが届く限り、判断していたのは旧コードだった。

Running-Code Primacy が区別するのは、まさにこの二つである。文書は採用可能な状態を提示する。実行中のコードは、どの状態が現実の権限を持つかを示す。

往復時間を必要としない376バイト

Sapphire とも呼ばれる Slammer は、2003年1月25日土曜日の05:30 UTC 直前に広がり始めた。ワーム本体は376バイトで、ヘッダーを含む UDP/IP パケットは CAIDA の記述で404バイトだった。脆弱なサービスでオーバーフローを起こすと、新たな感染ホストは同じ本体を疑似ランダムな IP アドレスの UDP 1434へ送り続けた。

接続確立も相手の返答も要らない。TCP を使うスキャナーなら接続やタイムアウトに拘束される。Slammer は一つ送れば次へ進むため、主な上限は往復遅延ではなく感染ホストの送信能力とアクセス回線だった。

CAIDA が直接観測した最大の単一ホストは毎秒約26,000プローブ。初期の感染インスタンス当たり平均は毎秒約4,000と推定された。開始から約3分で全体の走査率は毎秒5,500万を超え、10分以内に到達可能な脆弱ホストの90％超が感染した。

74,856という数字は、最初の30分に観測した異なる感染 IP アドレスの下限である。ワームの疑似乱数生成器には欠陥があり、観測地点によってはアドレス周期を丸ごと見落とす。初期の重要なトレースも約2分40秒で一時停止した。したがって世界全体の正確な感染台数とは書けない。ただし、主要な感染波が通常の人手による承認より速かったという結論は変わらない。

外からの洪水ではなく、内側の送信だった

Slammer は memcached 反射攻撃とは異なる。被害者の送信元アドレスを偽り、第三者に大きな応答を返させる仕組みではない。感染した SQL Server 自身が、自分のネットワークから走査パケットを発信した。観測された変種には別の破壊ペイロードがなかったが、増殖だけで回線を破壊できた。

多くの拠点では、1台か数台が使える限りの速度で送信し、最初の共有ボトルネックを埋めた。同じリンクの背後にある非脆弱な機器まで通信できなくなる。高い総量、小さなパケットの高頻度、次々に変わる宛先という組み合わせは、ネットワーク機器の CPU、メモリー、キューにも負荷を与えた。感染ホスト同士が容量を奪い合い、ワーム自身の増加率まで鈍らせた。

入口だけを守る境界モデルでは足りない。見落とした内部ランタイムが、組織自身の出口を独占するからである。必要なのは、外向きフローの異常検知、セグメンテーション、公平なキュー、レート制限、あるいはサイト全体を止めずに1台だけを隔離する権限である。遠隔の DDoS 緩和サービスへ任せる前に、ローカルリンクが失われる。

MSDE は別の製品名で入ってくる

MSDE 2000は他のアプリケーションに組み込めるデータベースエンジンだった。「SQL Server は導入していない」という資産台帳でも、業務ソフトの依存関係として Resolution Service が動いている場合がある。CERT/CC は、MSDE 2000を含む製品も影響を受けると明記した。

部品の脆弱性を知る Microsoft、組み込み先を知るディストリビューター、業務用途を知るアプリケーション担当、UDP 1434を見るネットワーク担当。それぞれの台帳だけでは実態にならない。

確認単位は製品名ではなく実行 ID である。どのプロセスが待ち受け、どのファイルバージョンをロードし、何が導入し、誰が停止リスクを負い、どのクライアントから到達できるのか。変更票の完了印ではなく、この照合が採用証拠になる。

MS02-061 の再公開経緯も単純な命令を難しくする。当初の組み合わせは一部環境で SQL Server の運用を妨げる可能性があり、Microsoft は追加の非セキュリティ修正と新しいインストーラーを統合した。脆弱なまま放置する理由にはならない。運用結果を負う当事者が互換性を試験し、変更を実施し、正しいプロセスが動いたことを確認しなければならない理由である。

1時間以内のフィルターは回復に効いた

CAIDA によれば、多くのサイトは発生から1時間以内に宛先 UDP 1434のフィルタリングを始めた。識別しやすいパケット、狭いポート、一般に重要なインターネット用途が少ないという好条件がそろっていた。それでも最初の人手フィルターは、感染可能なホストのほぼ全てが感染した後だった。

だから無意味だったわけではない。継続する走査量を抑え、回線回復を助けた。しかし既存感染を取り消せず、境界を通らない内部セグメント間の伝播も止められない。Cisco の運用資料は、ルーターACL と VLAN 内部へ作用する制御を分け、正当な業務で1434が必要なケースも示した。

必要なのは無制限の自動権限ではない。特定の署名、急激な宛先拡散、端末の役割に合わない送信率が同時に現れた場合だけ、一時的な制限や隔離を許す。閾値、対象、例外、最大時間、証拠保存、解除はローカル所有者が決める。

共通の最小仕様は三つの結果で足りる。影響を受けるランタイムを知る。不必要な到達性をなくす。1台に共有資源を独占させない。実装の選択は各ネットワークに残る。

採用には別々の証拠が要る

ベンダーは識別可能な修正版と現実的な導入経路を示す。ディストリビューターは組み込み部品を製品と顧客へ結び付ける。アプリケーション所有者はロード済みバージョン、依存関係、到達性を示す。ネットワーク運用者はフローと演習によって、単一端末がリンク全体を奪えないことを示す。

ファイアウォールは脆弱コードを隠せても直さない。パッチは不要な公開を正当化しない。台帳は古くなり得る。範囲が広すぎる隔離策は本番で実行できない。四つの証拠は代替関係ではない。

同時に、中央集権も不要である。Microsoft が顧客ネットワークを統治しなくても修正は公開できる。ネットワーク運用者が SQL Server を書き換えなくても共有容量は守れる。次の当事者が判断できる状態を見せ、損失と復旧を負う側に実行権を残すことが、協調の境界になる。

証拠の限界

資料から確認できるのは、事前に公開された修正、1データグラムに収まるワーム、少なくとも74,856の観測アドレス、数分単位の感染波である。全ての SQL Server や MSDE が公開されていたとは言えず、下限を世界総数にはできない。報道された個々の障害が同じ因果経路だったとも断定しない。

送信元詐称、反射、情報窃取、追加の破壊ペイロードも、この変種の説明には含めない。残る結論は明確である。公開済みパッチは、動き続ける旧バイナリから権限を奪わない。伝播が人間の許可より速いなら、限定した自動権限を先に設計し、バージョン、ソケット、フロー、演習で採用を証明する必要がある。

出典