要約

  • RFC 3128はtiny fragmentとoverlapという既知の技法を組み合わせ、filterが審査したTCP headerとhostが再構成したheaderを分離した。
  • 対策は、offset zeroのTCP fragmentにpolicy判断に必要な最小header全体を要求し、offset oneも引き続き拒否することだった。
  • 成否はfilter ruleと再構成実装に依存し、fragmentの通過だけではconnection成立、service侵害、全実装共通の脆弱性を証明しない。

境界装置が最初に見たpacketは、規則に反していなかった。IPv4 Fragment Offsetはzeroで、TCP headerには外部からの接続を許すserviceのportが入っている。control flagも判断に使える位置まで見えている。そこで通過を認めることは、その時点の表示に対しては筋が通っていた。

しかし、その表示はまだ完成品ではなかった。

RFC 3128の例では、最初のfragmentがoffset zeroから始まり、少なくとも十六byteのTCP headerを持つ。source port、destination port、sequence number、そして後続のcontrol fieldをfilterが関連づけられる長さである。

次のfragmentもoffset zeroから始まるが、transport部分は八byteしかない。この短い断片はportとsequence numberを覆い直し、後ろのTCP flagまでは含まない。攻撃者はここでdestination portだけを、incoming connectionを許可されていないportへ替えられる。三つ目のfragmentがdatagramを完成させる。

受信側のoverlap処理が後から来た短いbyte列を優先すれば、再構成されたheaderは二つの版を混ぜる。destination portは第二片から、control flagはfilterを通過した第一片から得られる。filterが許可したtransport headerと、TCPが受け取るtransport headerが同じではなくなる。

この組み合わせが狙ったのはRFC 1858のIndirect Methodだった。同文書は、必要なTCP fieldを第一片の外へ追い出すtiny-fragment attackと、重複byteの選択差を使うoverlapping-fragment attackを別々に説明した。Indirect MethodはFragment OffsetがoneのTCP fragmentを落とす。

IPv4 offsetの単位は八byteである。offset oneを禁じれば、最初の八byte直後からcontrol flagを別片に置く典型的な分割を止められる。第一片が判断材料を持つという期待には、それなりの根拠があった。

RFC 3128は、置換片をoneから始める必要がないと示した。zeroへ戻ればよい。防御は「次の位置」を封じたが、「zeroから始まるfragmentが常に十分長い」という条件までは検証していなかった。

ここではcontrol surfaceが分かれている。senderは断片境界、offset、順序、重複byteを選ぶ。filterはその場で見える表示を許可する。destination IP stackはどのbyteを残すか決める。TCPは完成したsegmentを受理するか決め、serviceはconnectionの続きを決める。一つの層の記録だけで、全ての結果を語ることはできない。

RFC 3128自身も断定を避けた。結果はdestination hostの正確な再構成実装に依存する。RFC 791はfragmentationとreassemblyの基本を定め、RFC 815は穴と重なりを扱う実用algorithmを示した。しかし、path上の全装置が重複byteに同じ勝者を選ぶという普遍的な保証はなかった。

この不確実性は、「全hostが弱い」という主張を退ける一方、「endpointもfilterと同じ意味にするはずだ」という期待も退ける。途中装置が完全なreassemblyもnormalizationも行わずに転送するなら、最終的なbyte選択を別の実装へ委ねている。

RFC 3128の修正は小さい。TCPでoffsetがzero、しかもtransport lengthが完全な最小headerより短ければdropする。offset oneもdropし続ける。portやflagを根拠にpolicyを適用するなら、その最小field集合が第一片に揃っていることを条件にするのである。

この条件は八byteの置換片を閉め出すが、IPv4の曖昧さ全体を消すものではない。全firewallに完全再構成を命じず、全旧stackのoverlap policyを統一せず、通過したfragmentがTCP handshakeを終えたとも述べない。network admission、transport acceptance、listening service、application effectは別の証拠である。

後の標準はより強い境界を選んだ。RFC 5722はIPv6でoverlapがあればdatagram全体を破棄するよう求めた。RFC 7112は第一IPv6 fragmentに完全なheader chainを要求した。RFC 6274はIPv4 securityを再検討し、RFC 8900はendpointとmiddleboxの差によってfragmentationが運用上壊れやすいことを整理した。

これらを2001年の製品へ逆投影してはいけない。後続文書が裏づけるのは特定製品の被害ではなく、構造である。enforcement pointとconsumerが同じobjectを見ていなければ、局所的に正しいruleもend-to-endでは別の意味になる。

同じ型はHTTP proxyとorigin serverのpath normalization、複数回のdecode、重複fieldのmergeにも現れる。攻撃手法は違うが、判断後にpolicy-relevantなfieldが変わるというauthority gapは共通している。

RFC 3128の歴史的価値は、許可と結果を分けたことにある。filter logはfilterが見たbyteと適用したruleの証拠である。それだけではTCPに渡ったport、connection成立、serviceへの影響を証明しない。最終結果を語るには、元のfragment setと実際のreassembly rule、その後のprotocol stateが必要である。

出典