パスワードを忘れた? アカウント作成
8000 story

TCPに容易にDoS撃を可能とする脆弱性 102

ストーリー by Oliver
性善説でよかった時代はとう終わっている 部門より

zophos 曰く、 "NISCC2004/4/20に発表したアドバイザリによると,TCPに,「長時間接続を維持し続け,ソースアドレス,デスティネーションアドレス,ポートが既知かあるいは推測可能なアプリケーションに対し,容易にサービス不能攻撃を可能とする脆弱性」が見つかったそうです。(CAN-2004-0230)
同アドバイザリでは特にBGPに対して言及されていますが,常時接続が当たり前となった現在,長時間接続を維持し続けるのはルータだけとは限らなくなっています。とりあえずの対処法として,

  • IPSecを使用しエンベロープを隠蔽する。
  • TCP Windowサイズを小さめにとる
  • ソースポート情報を発信しない

があげられていますが,いずれもあまり現実的な対処方法とは言えません。各ベンダから今後発表される情報に十分注意する必要があるでしょう。"

発信元と送信先それぞれのIPアドレスとポート番号を知っていれば、コネクションをリセットするパケットを捏造できてしまう、という話だ。発信元を認証せず、なおかつ単独のパケット1個で接続を切断できてしまうのはプロトコルのデザイン上の意図的な弱点といえる。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 新聞報道 (スコア:3, 興味深い)

    by Minap (9371) on 2004年04月21日 12時39分 (#535721) ホームページ 日記
     読売新聞の記事 [yahoo.co.jp]が出ていましたが、これだけ読むとかなり大事のように見えてしまう。

     ・・・というか、「ハッカーの侵入を許す重大な欠陥」ってのは正しい表現じゃないような気がするんだが。(w;
    --
    --- どちらなりとご自由に --- --
    •  米国土安全省などによると、欠陥を修理するソフトウエアの導入により攻撃の回避は可能で、これまでのところこの欠陥の悪用例はないとしている。

      と、あるのですが、これっていったい何のことなんでしょう?

      --
      むらちより/あい/をこめて。
      親コメント
  • 要は、オレオレ? (スコア:3, おもしろおかしい)

    by Anonymous Coward on 2004年04月21日 16時33分 (#535813)
    クライアント:サーバーちゃん? オレだよ、オレ。
    サーバー:192.168.1.1ちゃんかい?
    クライアント:そうそう、192.168.1.1だよ。
  • by KAMUI (3084) on 2004年04月21日 9時21分 (#535597) 日記
    TCP Vulnerability Published [slashdot.org]

    いきなり「OpenBSD is safe?」なんて反応が返ってる辺り
    対応早いな~?とか思ったりして>Theo
  • by Anonymous Coward on 2004年04月21日 12時08分 (#535694)
    JPCERT/CC から JPCERT/CC Alert 2004-04-21(1) のメールが来ました。Web では以下に掲載されています。これによると、タイトルは、

    TCP プロトコルに潜在する信頼性の問題 [jpcert.or.jp]

    と表現されています。冒頭を引用するとこういう表現になっています。
    I. 概要
        インターネット上で広く用いられているプロトコル「Transmission Control Protocol (TCP)」について、古くから知られている問題に対し、実装方法に関する改善策が公開されました。この改善策が指摘している TCP プロトコルの問題の結果として、接続中の TCP セッションが切断されたり、TCP ストリーム中に不正なデータを挿入されたりする可能性があります。
    • by Anonymous Coward on 2004年04月21日 13時41分 (#535746)
      古くから知られている問題に対し、実装方法に関する改善策が公開されました。
      という文章を読んで、問題自体は既知のもので、対策方法が公開されたから話題になっているんだと、理解してしまいましたが、どうも違うみたいですね。

      セキュリティホールmemoの解説 [ryukoku.ac.jp]によると、

      古来から知られている TCP リセット攻撃について、従来認識されていた「(2^32)/2 (= 2,147,483,648) 個のセグメントを作成する必要があり、それほど容易ではない」よりも容易に行える方法が発見 [blackhat.com]された模様。詳細は draft-ietf-tcpm-tcpsecure-00.txt: Transmission Control Protocol security considerations [ietf.org] (IETF) を参照。
      とあるので、JPCERT/CCが言う「実装方法に関する改善策」というのは、
      • 実装方法 = 攻撃プログラムの実装方法
      • 改善 = 攻撃プログラムの実装方法の改善
      ということなんでしょうか?
      「策」というのは違う気がしますが。
      親コメント
  • by suntear (11933) on 2004年04月21日 6時29分 (#535540) ホームページ 日記
    攻撃が問題となった時に SYN Cookie で対処したように、何らかの対策はできそうですね。直感ですが、、、
    • Re:SYN flood (スコア:3, 参考になる)

      by flatline (5514) on 2004年04月21日 7時38分 (#535546)
      実装の問題というよりも、今回はプロトコルそのものの問題なので、最終的にはRFC793を修正する必要がありますねぇ.
      最も影響をうけるBGPについてはTCP MD5 Signature Option(RFC2385)などの回避作も推奨されているようです.
      親コメント
      • by brake-handle (5065) on 2004年04月21日 12時35分 (#535718)

        ただし、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の鍵にしてしまうなど。

        親コメント
        • 鍵交換にそういう方法を使うとman-in-the-middle-attackくらうぞと怒らるのですが,話をTCPに絞って云えば今回の件にはあるていど有効だし,なにより面倒がなさそうなので,低コストでの実現方法があるとそれなりにうれしいかもしれないですね
          親コメント
          • 各々のendが事前に何らかの知識を(第三者を経由する場合を含めて)共有することなしにman-in-the-middleを防ぐというのは、本質的に不可能ではないでしょうか。TCPは通信相手に対してゼロ知識を仮定しなければならないので、相手を認証する手立ては全くありませんよね。高々、攻撃にさらされる時間を短縮するぐらいしかできないと思います。

            ところで、もしこの弱点を狙い、TCPのendではない計算機が攻撃をかけようとすると、IP packetのsource addressをspoofしなければなりません。となると、攻撃元のゲートウェイにおいてsource addressのspoofを弾くようにすれば、TCP接続の経路になり得ないネットワークからの攻撃は防げるのではないでしょうか。もちろん、経路上にあるルータからは依然として攻撃できてしまいますが...

            親コメント
            • いや,man-in-the-middle-attackができるから良くない,というわけではないです.
              知識共有はあまりにもコストが高く付き過ぎるので,中間者攻撃が可能なら可能でかまわないから,軽くて安いちょっとした防御ができたらいいなぁと.それだけです
              そこまで心配する危険性でもないのかもしれませんが

              ところで,この件ではsnoopはないという前提だと思います.アドレスも推測するだけだと思います.
              snoopできれば,window sizeなど関係なくピンポイントでシーケンス番号を決められるので簡単にコネクションを切れます.
              今回のは,経路上にいないホストからなんとなくのあてずっぽうで撃った時に,思っていたより的が大きくて当たりやすいんじゃないかしら,ということです
              親コメント
              • あれ... TCP接続経路上にない計算機がsource addressのsnoopなしに攻撃することって本当に可能ですか? TCP接続って、(source address, source port, destination address, destination port)の4つ組で定義されると思ったんですけど。4つ組の各々に(例えばBSDの場合)PCBが割り当てられるので、第三の計算機から攻撃する場合はspoofしないとPCB lookupが失敗すると見たんですが...

                親コメント
              • 訂正: s/snoop/spoof/

                FreeBSDのin_pcblookup_hash()で調べてみましたが、最終的には先の4つ組をすべて調べてますね。pseudocodeはこんな感じです。

                in_pcblookup_hash(
                 faddr /* 他計算機アドレス */,
                 fport /* 他計算機ポート */,
                 laddr /* 自計算機アドレス */,
                 lport /* 自計算機ポート */)
                {
                 hash = PCBHASH(faddr, fport, lport);
                 foreach inp in hash {
                  if (inp->faddr == faddr
                   && inp->fport == fport
                   && inp->laddr == laddr
                   && inp->lport == lport)
                    return (inp);
                 }
                 return (NULL);
                }
                親コメント
      • by fuchikoma (2044) on 2004年04月21日 8時27分 (#535564)
        回避策を適用するときは、自分のところの機器だけでなく、接続先の対向機器
        も同じ回避策を適用する必要がある...という理解でいいのでしょうか?
        親コメント
  • by Kenneth (10065) on 2004年04月21日 10時26分 (#535632)
    >発信元と送信先それぞれのIPアドレスとポート番号を知っていれば、
    >コネクションをリセットするパケットを捏造できてしまう、という話
    >だ。発信元を認証せず、なおかつ単独のパケット1個で接続を切断で
    >きてしまうのはプロトコルのデザイン上の意図的な弱点といえる。

    これって、ネットワーク型のIDS製品がパケットを止めるために使っている手法とかと異なるんでしょうか?(それが出来るようにしたのが意図的な弱点?)
    • Re:IDS製品 (スコア:2, 参考になる)

      by satsuki (5219) on 2004年04月21日 10時37分 (#535643) ホームページ 日記
      もともと通信経路の途中にいる人にとってはTCPコネクションを切ることはそれほど難しいことではなかったのですが,今回のは,経路の途中にいない人からのあてずっぽうの攻撃でも,想定していたよりずっと攻撃成功率が高かったという話です.
      親コメント
  • とりあえずFINがきたら・・・

    FINに書いてあるシーケンスへ到達するまでFINやCLOSEに行かず、
    シーケンスNO.に到達したとき、SEQの区切りがFINと一致しなければFINを破棄、ってのは
    駄目ですかね?

    --
    いなんず[いつでも前向きでイタい]
    • 未解決のFINが6万個ほどたまる罠。
      親コメント
      • んーでも管理する要素数はウインドウサイズより必ず小さいわけだし、
        ウィンドウサイズより一回り大き目のビットマップを用意してFINの位置を記録、
        それを順繰りに再利用する・・・でいいんじゃ?
        --
        いなんず[いつでも前向きでイタい]
        親コメント
    • あれ?FINが来ただけで切断に行っちゃうんでしたっけ?
      RSTとSYN以外はシーケンスがあってないと処理されないはずじゃ...
      と、思ってたんだけど。
      # とりあえずRST無視すればだいぶ防げそうな気がしますが。
      # それじゃダメな場合もあるでしょうが。
      親コメント
      • えっと・・・・解釈あってるのか激しく自信がなくなってきた。

        たとえばAとBで通信してて、
        A->B、B->AもSEQが10になったところ、
        ウインドウサイズが10として(ちいさ!)
        AがBにACKだけ返すところからはじめる・・こんな感じ?

        1. B->A Flag=ACK, SEQ=10, ACK=10
        2. A->B Flag=ACK, ACK=10, SEQ=12 "AB" #ウインドウの中にあった残りパケット
        3. A->B Flag=ACK, ACK=10, SEQ=14 "CD" #ここまでは普通
        4. A->B Flag=ACK/FIN, ACK=10, SEQ=15 #攻撃パケット
        5. A->B Flag=ACK, ACK=10, SEQ=16 "EF" #さらにバッファされていた続きのウインドウ内パケット

        このとき、4番目のパケットと、本来来るはずの5番目のパケット、
        どっちが有効か?って問題のような気がする。
        次に来るパケットのSEQがウインドウ内であれば有効なパケットなのだから
        切断パケットが届いたことが有効とすると、5は無効なSEQとして無視しないといけない。
        もしそうしたとしても・・・次にBがやるところから想像すると、

        1. B->A Flag=ACK, SEQ=10, ACK=14 #BはSEQ=15の内容を期待してリトライ
        2. A->B Flag=ACK, SEQ=16, ACK=10 "EF"#AはSEQ=15に異物が挟まった事に気が付かない
        3. B->A Flag=ACK, SEQ=10, ACK=14 #BにとってはSEQ=15の存在は無視できないのでSEQ=16は捨ててリトライする
        4. A->B Flag=ACK, SEQ=15, ACK=10 "E" #パケットサイズを小さくしてリトライ、だがこうするとこの時点で切断が成立してしまう。

        って事に・・?

        あってますかね・・・・

        --
        いなんず[いつでも前向きでイタい]
        親コメント
        • その例だとシーケンス番号が一致してる&攻撃パケットが先に届くので攻撃成
          功っぽいですが、

          1. B->A Flag=ACK, SEQ=10, ACK=10
          2. A->B Flag=ACK, ACK=10, SEQ=12 "AB" #ウインドウの中にあった残りパケット
          3. A->B Flag=ACK, ACK=10, SEQ=14 "CD" #ここまでは普通
          4. A->B Flag=ACK/FIN, ACK=10, SEQ=16 #攻撃パケット
          5. A->B Flag=ACK, ACK=10, SEQ=16 "EF" #さらにバッファされていた続きのウインドウ内パケット

          と、こんな感じで攻撃パケットはウインドウに入ってるけどシーケンスはまだ
          先、かつ将来も攻撃パケットのシーケンスは一致しない。みたいな状況だと攻
          撃は失敗するんじゃないかな。と思ったわけです。
          # 5でAが1オクテットしか送らなかったらその時点で成功でしょうけどね。
          親コメント
  • by Anonymous Coward on 2004年04月21日 11時06分 (#535659)
    アドバイザリからたどれるCiscoの中の人が書いたInternetDraft [ietf.org]。BGPが名指しされてるから、ルータ屋さんとしては必死になる罠。
typodupeerror

目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond

読み込み中...