SQL Slammer（376バイトで世界を止めた）

何のコードか（背景と何が有名か）

SQL Slammer（別名 Sapphire）は、2003年1月25日 05:30 UTC ごろに突如出現し、わずか10分で世界のインターネットを実質的に麻痺させたワームです。有名なのは、その常識外れの速さと極端な小ささにあります。ワーム本体は 376バイト、UDP/IP のヘッダを足しても 404バイトの単一パケットに丸ごと収まりました。ソースコードでもファイルでもなく、たった1つのパケットが自分自身のコピーを撒き散らす「生きた弾丸」だったのです。

標的は Microsoft SQL Server 2000 と、それを内蔵する MSDE 2000 の 解決サービス（SQL Server Resolution Service, SSRS）が待ち受ける UDP ポート 1434 でした。ここに存在したバッファオーバーフローを突いて任意コードを実行させます。CAIDA を中心とした事後解析によれば、感染ホスト数は約 8.5秒で倍増し、出現から 3分足らずでピーク毎秒5500万スキャンに達し、約10分で脆弱ホストの 9割・7万5千台超を飲み込みました。これは当時「史上最速のワーム」と呼ばれ、今なお指数増殖の破壊力を示す教科書的事例です。

コードと仕組みの解説

横にスクロール

Slammer の本体は、ハンドチューニングされたアセンブリの塊です。動作は「オーバーフローで実行権を奪う」→「必要な関数を自力で解決する」→「乱数IPへ自分を撃ち続ける」の3段です。

1. オーバーフローと制御奪取。 SSRS は 0x04 で始まるパケットを受けると、続くデータをスタック上のバッファへ長さ検査なしにコピーします。攻撃パケットはこのバッファを溢れさせ、関数の戻りアドレスを書き換えます。書き込む値は sqlsort.dll 内に存在した jmp esp 命令のアドレス 0x42B0C9DC です。関数が戻ると jmp esp が実行され、実行位置は「スタック上に居座った攻撃データ自身」へ飛びます。以降はそこに置かれたワームコードが走ります。

# 制御奪取の骨子（概念）
[SSRSが受信]  0x04 + 長い文字列 …… 長さ検査なしでスタックへコピー
[溢れる]      戻りアドレスを 0x42B0C9DC（sqlsort.dll の jmp esp）で上書き
[ret 実行]    jmp esp → esp が指すスタック上の攻撃データへジャンプ
[payload]     スタックに載ったワーム本体が実行開始

固定アドレスへ飛ぶ設計だからこそ、当時 ASLR（アドレス空間配置のランダム化）が無い Windows では、脆弱なホストならどれでも同じ一撃が通りました。

2. 関数の自力解決。 ディスクに何も書かないため、必要な API は実行時に自分で見つけます。まず kernel32.dll を起点に GetProcAddress と LoadLibraryA の番地を得て、ws2_32.dll（ソケット）を読み込み、socket・sendto と、乱数の種に使う GetTickCount を解決します。

3. 乱数IPへの無限送信。 ここが増殖エンジンです。GetTickCount（起動からの経過ミリ秒）を種に、線形合同法（LCG）で疑似乱数を生成し、それを32ビットの標的IPとして UDP 1434 へ 404バイトを撃ちます。応答は一切待たず、生成と送信をひたすら回す「撃ちっぱなし（fire and forget）」です。

# 増殖ループの骨子（擬似コード）
seed = GetTickCount()
loop:
    seed = seed * A + B          # 線形合同法で次の疑似乱数
    target_ip = seed             # 32ビットをそのままIPと解釈
    sendto(target_ip, port=1434, payload)   # 404バイトを送出、応答は待たない
    goto loop                    # 回線帯域が許す限り最速で反復

なぜ「速すぎた」のか。1台の感染ホストは回線が許す限り毎秒数万パケットを吐き、そのたびに新しい感染源が増えます。応答待ちがないため CPU と帯域だけが律速で、増殖は純粋な指数関数を描きました。さらに大量の UDP パケット自体がルータのバッファを溢れさせ、BGP セッションが切れるなどインターネットの土管そのものを詰まらせたため、感染していない組織まで通信不能に陥りました。ワームは自らの成功で通信路を壊し、結果的に自分の拡散も頭打ちにしたのです。

逸話と経緯

穴の発見者は、著名なセキュリティ研究者 David Litchfield（当時 Next Generation Security Software）でした。彼は2002年、この SSRS のオーバーフローを Microsoft へ報告し、Black Hat で概念実証を示しました。皮肉なことに、その後に公開された攻撃手法の考え方が、素性不明の作者によってワーム化されます。Slammer の作者は今日まで特定されていません。

決定的な事実は、パッチが半年前に出ていたことです。悪用された脆弱性は 2002年7月24日の MS02-039 で修正され、同年10月の累積パッチ MS02-061（および SQL Server 2000 Service Pack 3a）にも含まれていました。つまり出現の時点で、正しくパッチを当てた組織は無傷だったはずなのです。それでも被害が甚大だったのは、運用現場でのパッチ適用がいかに遅れがちかを露呈しました。パッチ適用時のファイル上書きの手順が煩雑で、当てたつもりが実は無防備、という事故も少なくありませんでした。

対応は、UDP ポート 1434 を境界ルータ・ファイアウォールで遮断し、感染ホストを再起動して（メモリ常駐のみなので再起動で本体は消える）パッチを当てる、という順序で進みました。ワームは自己増殖の速さゆえ数十分で飽和し尽くしたため、拡散のピーク自体は短時間で過ぎ去りました。

遺産と教訓

Slammer は「小さいコードほど無害」という直感を完全に裏切りました。要点を整理します。

第一に、パッチ適用は技術ではなく運用の問題だという教訓です。修正コードは存在したのに、それが現場に行き渡っていなかった。脆弱性管理とは「パッチを作ること」ではなく「漏れなく当て続け、当たっていることを確認し続ける」プロセスだと業界が痛感しました。第二に、攻撃面（アタックサーフェス）の最小化です。多くの被害ホストは、そもそも外部から UDP 1434 が見える必要のないサーバーでした。既定で拒否し、必要なものだけ開ける原則が徹底されていれば被害は激減したはずです。第三に、単一パケットのコネクションレス攻撃という設計原理そのものが、後年の DDoS やインターネットワームの脅威モデルを定義しました。

バッファオーバーフローがなぜ制御奪取に直結するのかというメモリとスタックの原理はセキュリティの基礎に、コネクションレスな UDP が往復を持たない仕組みはネットワークの基礎に立ち返ると腑に落ちます。376バイトが世界を止めた事実は、コードの大きさと影響の大きさが無関係であること、そして最後に世界を守るのは派手な技術ではなく地味なパッチ適用であることを、20年以上経った今も静かに教え続けています。