TCPに容易にDoS撃を可能とする脆弱性 102
ストーリー by Oliver
性善説でよかった時代はとう終わっている 部門より
性善説でよかった時代はとう終わっている 部門より
zophos 曰く、 "NISCCが2004/4/20に発表したアドバイザリによると,TCPに,「長時間接続を維持し続け,ソースアドレス,デスティネーションアドレス,ポートが既知かあるいは推測可能なアプリケーションに対し,容易にサービス不能攻撃を可能とする脆弱性」が見つかったそうです。(CAN-2004-0230)
同アドバイザリでは特にBGPに対して言及されていますが,常時接続が当たり前となった現在,長時間接続を維持し続けるのはルータだけとは限らなくなっています。とりあえずの対処法として,
- IPSecを使用しエンベロープを隠蔽する。
- TCP Windowサイズを小さめにとる
- ソースポート情報を発信しない
があげられていますが,いずれもあまり現実的な対処方法とは言えません。各ベンダから今後発表される情報に十分注意する必要があるでしょう。"
発信元と送信先それぞれのIPアドレスとポート番号を知っていれば、コネクションをリセットするパケットを捏造できてしまう、という話だ。発信元を認証せず、なおかつ単独のパケット1個で接続を切断できてしまうのはプロトコルのデザイン上の意図的な弱点といえる。
新聞報道 (スコア:3, 興味深い)
・・・というか、「ハッカーの侵入を許す重大な欠陥」ってのは正しい表現じゃないような気がするんだが。(w;
--- どちらなりとご自由に --- --
Re:新聞報道 (スコア:1)
と、あるのですが、これっていったい何のことなんでしょう?
むらちより/あい/をこめて。
Re:新聞報道 (スコア:1, すばらしい洞察)
仮に訂正記事を載せたとしても、
その訂正記事の中で正しく説明できるとは思えません。
誤報は良い事ではないし、当然ながら減らす努力はすべきですが、
新聞自体、制限の多い(相対的に)低機能なメディアなので、
過剰な期待をかけるのは考えものです。
Re:新聞報道 (スコア:1)
アベンド... ABnormal ENDの略でしたっけ?久々に聞いた気がする。
Re:新聞報道 (スコア:2, おもしろおかしい)
# ええ、ネタですとも。
要は、オレオレ? (スコア:3, おもしろおかしい)
サーバー:192.168.1.1ちゃんかい?
クライアント:そうそう、192.168.1.1だよ。
Re:要は、オレオレ? (スコア:1, おもしろおかしい)
本家でも記事になってます。 (スコア:2, 参考になる)
いきなり「OpenBSD is safe?」なんて反応が返ってる辺り
対応早いな~?とか思ったりして>Theo
Re:本家でも記事になってます。 (スコア:1)
Super Souya
Re:RFC != 仕様 (Re:本家でも記事になってます。) (スコア:1, おもしろおかしい)
Re:本家でも記事になってます。 (スコア:1, 参考になる)
「TCPプロトコルに潜在する信頼性の問題」 (スコア:2, 参考になる)
TCP プロトコルに潜在する信頼性の問題 [jpcert.or.jp]
と表現されています。冒頭を引用するとこういう表現になっています。
Re:「TCPプロトコルに潜在する信頼性の問題」 (スコア:3, すばらしい洞察)
セキュリティホールmemoの解説 [ryukoku.ac.jp]によると、
とあるので、JPCERT/CCが言う「実装方法に関する改善策」というのは、「策」というのは違う気がしますが。
SYN flood (スコア:1)
Re:SYN flood (スコア:3, 参考になる)
最も影響をうけるBGPについてはTCP MD5 Signature Option(RFC2385)などの回避作も推奨されているようです.
3-way handshakeで鍵を共有しては? (スコア:2, 興味深い)
ただし、MD5 Signatureはend-to-endで鍵が共有できていることを仮定しています。もしアプリケーションに依存せず、すべてのTCP接続でこれをやろうとしたら、IKEか何かを動かさないと使いものにならないでしょうね。
3-way handshakeの間にend-to-endで鍵を共有することができれば、TCPだけでheaderの認証ができないでしょうか。例えばDiffie-Hellmanのexponentialを最初のSYNおよびこれに続くSYN + ACKのTCP optionに載せて、それをMD5 Signatureの鍵にしてしまうなど。
Re:3-way handshakeで鍵を共有しては? (スコア:1)
Re:3-way handshakeで鍵を共有しては? (スコア:1)
各々のendが事前に何らかの知識を(第三者を経由する場合を含めて)共有することなしにman-in-the-middleを防ぐというのは、本質的に不可能ではないでしょうか。TCPは通信相手に対してゼロ知識を仮定しなければならないので、相手を認証する手立ては全くありませんよね。高々、攻撃にさらされる時間を短縮するぐらいしかできないと思います。
ところで、もしこの弱点を狙い、TCPのendではない計算機が攻撃をかけようとすると、IP packetのsource addressをspoofしなければなりません。となると、攻撃元のゲートウェイにおいてsource addressのspoofを弾くようにすれば、TCP接続の経路になり得ないネットワークからの攻撃は防げるのではないでしょうか。もちろん、経路上にあるルータからは依然として攻撃できてしまいますが...
Re:3-way handshakeで鍵を共有しては? (スコア:1)
知識共有はあまりにもコストが高く付き過ぎるので,中間者攻撃が可能なら可能でかまわないから,軽くて安いちょっとした防御ができたらいいなぁと.それだけです
そこまで心配する危険性でもないのかもしれませんが
ところで,この件ではsnoopはないという前提だと思います.アドレスも推測するだけだと思います.
snoopできれば,window sizeなど関係なくピンポイントでシーケンス番号を決められるので簡単にコネクションを切れます.
今回のは,経路上にいないホストからなんとなくのあてずっぽうで撃った時に,思っていたより的が大きくて当たりやすいんじゃないかしら,ということです
Re:3-way handshakeで鍵を共有しては? (スコア:1)
あれ... TCP接続経路上にない計算機がsource addressのsnoopなしに攻撃することって本当に可能ですか? TCP接続って、(source address, source port, destination address, destination port)の4つ組で定義されると思ったんですけど。4つ組の各々に(例えばBSDの場合)PCBが割り当てられるので、第三の計算機から攻撃する場合はspoofしないとPCB lookupが失敗すると見たんですが...
Re:3-way handshakeで鍵を共有しては? (スコア:1)
訂正: s/snoop/spoof/
FreeBSDのin_pcblookup_hash()で調べてみましたが、最終的には先の4つ組をすべて調べてますね。pseudocodeはこんな感じです。
自組織だけでなく (スコア:1)
も同じ回避策を適用する必要がある...という理解でいいのでしょうか?
IDS製品 (スコア:1)
>コネクションをリセットするパケットを捏造できてしまう、という話
>だ。発信元を認証せず、なおかつ単独のパケット1個で接続を切断で
>きてしまうのはプロトコルのデザイン上の意図的な弱点といえる。
これって、ネットワーク型のIDS製品がパケットを止めるために使っている手法とかと異なるんでしょうか?(それが出来るようにしたのが意図的な弱点?)
Re:IDS製品 (スコア:2, 参考になる)
たとえばの対処として・・・ (スコア:1)
FINに書いてあるシーケンスへ到達するまでFINやCLOSEに行かず、
シーケンスNO.に到達したとき、SEQの区切りがFINと一致しなければFINを破棄、ってのは
駄目ですかね?
いなんず[いつでも前向きでイタい]
Re:たとえばの対処として・・・ (スコア:1)
Re:たとえばの対処として・・・ (スコア:1)
ウィンドウサイズより一回り大き目のビットマップを用意してFINの位置を記録、
それを順繰りに再利用する・・・でいいんじゃ?
いなんず[いつでも前向きでイタい]
Re:たとえばの対処として・・・ (スコア:1)
RSTとSYN以外はシーケンスがあってないと処理されないはずじゃ...
と、思ってたんだけど。
# とりあえずRST無視すればだいぶ防げそうな気がしますが。
# それじゃダメな場合もあるでしょうが。
私の解釈があってるのかな・・・? (スコア:1)
たとえばAとBで通信してて、
A->B、B->AもSEQが10になったところ、
ウインドウサイズが10として(ちいさ!)
AがBにACKだけ返すところからはじめる・・こんな感じ?
このとき、4番目のパケットと、本来来るはずの5番目のパケット、
どっちが有効か?って問題のような気がする。
次に来るパケットのSEQがウインドウ内であれば有効なパケットなのだから
切断パケットが届いたことが有効とすると、5は無効なSEQとして無視しないといけない。
もしそうしたとしても・・・次にBがやるところから想像すると、
って事に・・?
あってますかね・・・・
いなんず[いつでも前向きでイタい]
Re:私の解釈があってるのかな・・・? (スコア:1)
功っぽいですが、
と、こんな感じで攻撃パケットはウインドウに入ってるけどシーケンスはまだ
先、かつ将来も攻撃パケットのシーケンスは一致しない。みたいな状況だと攻
撃は失敗するんじゃないかな。と思ったわけです。
# 5でAが1オクテットしか送らなかったらその時点で成功でしょうけどね。
まだリンクが無いみたいなんで (スコア:1, 興味深い)
Re:意図的な弱点? (スコア:5, 興味深い)
パケット網で効率的な通信を行うために, 確実性をある程度犠牲にしていると考えた方がよいかも.
TCPでは仮想的に1対1の通信路を確保しているわけですが, 下位のIPや物理的なネットワークではデータをパケット単位で分割して送っています. この時, パケット網の特性として
ということがあります. そのため厳密にパケットのシーケンス番号を守っていたのでは問題があり, ある程度の幅(ウィンドウサイズ)で受け入れる必要があります. このウィンドウサイズ内でパケット抜けがあれば, そのパケットだけ再送してもらえば良いので, 特に低速の回線の場合には効率も良くなります.
今回問題になっているような偽装パケットの場合, 直ちに仮想回線を切断するのではなく, そのシーケンス番号の直前のパケットまでが揃うのを待ち, さらに一定時間待って同一シーケンス番号が来ないことを確認してから切断するようにすれば良いかもしれません. ただしその場合, 本当に回線状態が悪かった時などはなかなか仮想回線を切断することができず, 計算機資源に影響が出そうです. また, 例えばシーケンス番号を32bit長ではなく128bit長とかにすれば下手な鉄砲が当たる確率はぐんと減るはずですが, これもパケット処理の負荷が問題になる(あるいはTCPの成立時には問題になった)でしょう. またウィンドウサイズを網の通信状態によって動的に変更すれば, 通信状態の良い網では耐性が高まるはずですが, これも処理が複雑になりそうですね.
Re:意図的な弱点? (スコア:1)
選択的再送ってTCPについてた? オプションにもあったっけ?
最近の実装ではある程度ながら実現してた気が。(Slew up とか)
Re:意図的な弱点? (スコア:1, 参考になる)
Selective ACK[RFC2018] [faqs.org]
Re:意図的な弱点? (スコア:2, 参考になる)
「仕様のバグ」と言い換えた方がいいかも。おそらくは何かの意図があってそのように設計されているのだけど、結果としてそれがセキュリティホールになりうる、と。
この手の話は「当時のハードウェアの能力からしてやむをえなかった」というオチが多いんだよなぁ…
概要 (スコア:5, 参考になる)
あとは"Slipping In The Window: TCP Reset Attacks"という原論文(名前しか出てない)を読んでみるしかないのかな.
Re:概要 (スコア:3, 参考になる)
シーケンス番号が変な(windowに入ってない)セグメントが来る、というのは RFC792(STD7) で言うところの Half-Open Connection の場合によくあることだと思います。
ただ、普通シーケンスがおかしいセグメントに対しては、次のシーケンスを示すACKを返して終わりですし、それだけでは乗っ取れないわけですが、RST は window 内に入ってればいいということで、目的が達成できる確率が高まるわけですね。
で、普通は切れたら張り直しておしまいなわけですが、BGPの場合、
BGP peerで使ってるアドレスをソースにしたパケットが外から入り込まないようにフィルタすればいいような気もするけど、IXだったりmultihopだったりすると面倒な場面もあるかも。
Re:概要 (スコア:2, 参考になる)
Re:概要 (スコア:2)
> * 従って,偽造パケットによりTCPコネクションを切られるDoS攻撃が成功する確率は1/(2**32)よりずっと大きい(実施可能なレベルになる).
なるほど。そうすると「攻撃の成功しやすさ」、は TCP window size による、ってことになりそうですね。
最近はブロードバンド接続にあわせて windows size を大きくするってのが流行ってますからその分危険性が増すってことでいいのかな。
ただ、この window size ってもとは 16k とか 32k のものが 256k とかそのぐらいになるだけだから極めて危険、ってわけでもなさげって理解でいいんでしょうか。
Re:概要 (スコア:3, 参考になる)
ということで確率としては最悪1/(2**16)ということになります
40億分の1から6万分の1になるというのは確かに恐い話ではありますが結局,数撃ちゃ当たる攻撃しかないし,しかも成功したかどうかが分からない攻撃というのは中々大変ではないかと思います
# もちろん途中でパケットを拾われていない,という条件で
Re:概要 (スコア:1)
でも,windowサイズはパケットを受ける側に決定権があるのでそんなに問題にはならないのかなと思います
Re:概要 (スコア:3, 興味深い)
> >これで1GBくらいまでいけそうです。
> これは、16bit空間を使って大きいWinサイズを表現する手法なので
> この脆弱性ネタとは関係ないような。。。(結局16bit)
RFC1323によって64KBより大きなwindow sizeを指定できるようになった。
すなわちwindow sizeはもはや64KBに制限されないということです。
このストーリーの脆弱性はwindow sizeが大きいほどリスクが大きい
ので、関係します。
# 実際、window size 1GBなら4回のトライで確実に切れるわけだ
Re:IPv6 は? (スコア:1)
Re:IPv6 は? (スコア:1)
わかってしまえばあとは同じですが
Re:IPv6 は? (スコア:1)
IPv6はIPSecの利用が義務付けられてますから、回避できるんではないかと。
Re:IPv6 は? (スコア:1, 参考になる)
IPv6 の仕様は IPsec を標準で含んでいるので、「IPsec のサポートが義務付けられている」とはいえるけど、IPsec を使うか使わないかはユーザの選択なので、「IPsec の利用が義務付けられている」なんてことはないですよ。
Re:まず議論をするために (スコア:4, すばらしい洞察)
Re:まず議論をするために (スコア:1)
# そういう問題じゃないですね :-p
Re:まず議論をするために (スコア:3, 参考になる)
#対応の緊急性の議論なら別だけど。
> 頻繁にコネクションが切れたら甚大な影響がでる
> アプリケーションが、BGP以外にどれだけあるのか挙げてみよう。
甚大なって程じゃないけど、個人的に「すごく困る」のは port fowarding に使ってる ssh のコネクションとかかなぁ。
端末としての telnet や ssh のコネクションは、「困るなぁ」ぐらいだし。
IP電話とかストリームでの画像監視とかは UDP だし。。。
まぁ、そういった意味では TCP コネクションってもともとは「すごく長時間」コネクション張りっぱなしにするってことはあんまり考えてないってことっぽいですね。
空豆 (スコア:1)
「タレコミちゃん」ってどんな人だろうかと思ってみたり。
やっぱ萌え系かな・・・。
# AA作成依頼してこよっかな。