ニュース
2004/04/26 15:20 更新


TCPの脆弱性、異常なトラフィックは「今のところ観測なし」

JPCERT/CCによると、TCPの脆弱性が原因と見られるトラフィックの増加や攻撃の兆候は観測されていないという。

　日本時間の4月21日に公になったTCPの脆弱性は、インターネットの根幹に影響を及ぼす可能性もあるとして大きく報道された。しかしJPCERT/CCによると、今のところ、この脆弱性が原因と見られるトラフィックの増加や攻撃の兆候は観測されていない。

　もちろんこの脆弱性は、TCPの仕様そのものに関わる根の深い問題であることに変わりはない。だがJPCERT/CCは、深刻さを客観的に判断すれば、今すぐにもこの脆弱性を悪用したワームが登場する恐れがある、といった危機的な状況にはないとしている。また情報処理推進機構（IPA）も、現時点ではこの脆弱性を「緊急対策情報」には含めていない。引き続き注意が必要なものの、事態の推移を見守るといった状況だ。

　実はJPCERT/CCでは過去数カ月間にわたり、NISCCやUS-CERTと連携しながら、国内の主要なベンダーや事業者との間で、この問題に関するコーディネーションを進めてきたという。一般向けアナウンスの段階で若干どたばたはあったものの、問題の影響を最小限に抑えられるだけの準備が行われていたということだ。

　JPCERT/CCは今年3月、「脆弱性情報ハンドリングワークショップ」を開催し、海外の組織と協調しながら、脆弱性情報の適切な収集・公開を行うための体制整備を進めていく方針を明らかにしている（3月10日の記事参照）。今回のTCPの脆弱性に関する情報収集およびコーディネーションも、この取り組みの一環として進められた模様だ。

　なお、今のところ各ベンダーの対応はまちまちだが、最新の状況は逐次JVN（JPCERT/CC Vendor Status Notes）を通じてアップデートしていくという。

根本的な問題解決はドラフト仕様で

　そもそもこの脆弱性は、十年近く前から知られてきた周知の問題だ。TCPの仕様（RFC793／1323）上、攻撃者が細工を仕込んだパケットを送り込むことによって、確立済みのTCPセッションをリセットする（＝切断する）ことができてしまうというものである。

　ただ、この攻撃が成功するにはいくつかの条件がある。1つは、攻撃者が当該セッションのソースIPアドレスとソース／デスティネーションのポート番号を知り、偽装していること。もう1つは、セッションごとに一意なシーケンス番号を推測し、これも偽装していることだ。

　後者の条件に含まれるシーケンス番号は32ビットの整数値であり、何もないところから推測しようとすると、約40億通り（2の32乗）の組み合わせの中から試行していかねばならない。したがって従来は、この仕様を悪用しての攻撃は困難だと考えられてきた。今回指摘されたのは、シーケンス番号の作成と密接な関係を持つウィンドウサイズが、ブロードバンド環境の普及などによって広がってきたことにより、推測がぐっと容易になり、攻撃を起こせる可能性が高まったという点である（別記事参照）。

　しかも、既に各所で指摘されているとおり、特に長時間続くTCPセッションではこの問題の影響が大きくなる。セッションが長く続けば続くほど、攻撃者にシーケンス番号の推測を許す余裕を与えることになるからだ。その例として取り上げられているのが、動的ルーティングに用いられるBGPである。

　BGPは、RIPやOSPFといった他のルーティングプロトコルとは若干異なり、サービスプロバイダーや大規模ネットワーク間のルーティングに利用されている。したがって、この問題をまず深刻に受け止めるべきは、こういったネットワークを運用している事業者（のルータ運用担当者）だ。ただ、BGPフルルートを食べるような重要なルータでは、この問題への対処は進んでいるという。

　ちなみに今回、TCPの脆弱性について警告した一連のアドバイザリでは、問題を緩和するための手段として「TCP MD5 Signature オプション（RFC2385）の有効化」「IPSecの利用」、そして「送信元IPアドレスが詐称されたパケットのフィルタリング」が挙げられている。また別記事のとおり、Cisco SystemsやJuniper Networksといった、BGPに対応したハイエンドルータのベンダーでは、問題を緩和するパッチの提供を開始した。JVNを確認すると、それ以外のルータ製品でも対応が進みつつあるようだ。

　この問題に対し、エンドユーザーレベルで打てる手立てはほとんどない（つまりサービスプロバイダーにお任せ、ということになる）。逆に言えば、ルーティングを行っているハイエンドユーザーやネットワーク管理者の場合は、パッチの入手やMD5オプションの利用といった対処を取る必要がある。必要以上に騒ぎ立てる必要はないが、たんたんと正確に緩和策を講じるべきだろう。

　ただ、「この問題は、たとえパッチを当てたとしても修正されるわけではなく、根本的な解決策はない」（JPCERT/CC）のも事実。これを機に、十年来のこの問題について考え直してみるべきではないかという。なお、現在ドラフト段階にある新たなTCP実装ではこの問題の解決が図られる予定だ。しかも、このドラフトは「一般のドラフトとは異なる手順で、早期にRFC化が図られるのではないかと見られている」（JPCERT/CC）という。

　また、同時期に公表されたCisco製品のSNMPの脆弱性や、一連のWindows製品の脆弱性については、TCPの脆弱性の問題よりもいっそう深刻と見られる。こちらにも十分な警戒が必要だ。

関連記事
▼ネットの「救世主」、真相を語る――TCP脆弱性の発見者が講演
▼「大げさに騒がれすぎ」：TCP欠陥を指摘したセキュリティ研究者
▼Cisco、TCPの脆弱性情報に対応
▼TCPにDoS攻撃を可能にする脆弱性
▼TCPの脆弱性、米英政府機関がアドバイザリー発行

関連リンク
▼JPCERT/CC：TCP プロトコルに潜在する信頼性の問題
▼NISCC Vulnerability Advisory 236929

[ITmedia]

Copyright © ITmedia, Inc. All Rights Reserved.