|
ネットワーク WG Request for Comments： 1858 分類： 情報提供 |
G. Ziemba Alantec D. Reed Cybersource P. Traina cisco Systems 1995年10月 |
このメモは、インターネットコミュニティに情報提供するものです。 これは、いかなるインターネット標準を定めるものではありません。 このメモの配布に制限はありません。
IPフラグメンテーションは、 ルーターやホストにおいて使用されているIPフィルタに対してTCPパケットを偽るのに利用することができてしまいます。 本書においては、2つの攻撃手法とともに、 それらを防ぐための救済策について述べます。
システム管理者は、 ネットワーキング機器にパケットフィルタ機能を付加して提供するのに、 それらのベンダーに依存します。； これらのフィルタは、 攻撃者がプライベートなシステムや情報にアクセスすることを防ぐ一方で、 友好的な主体がプライベートなネットやインターネット間でデータを転送することを許可するのに使用されます。 この理由で、ネットワーク機器のベンダーは、 自身の機器について想定される攻撃を予期し、 そのような攻撃をかわす丈夫な機構を実装することが重要です。
グローバルなインターネットの発展によって、 反社会的な行為であることが明らかになってきた「望まれない要素」の増加がもたらされました。 最近、インターネットホスト上で、目新しい攻撃法の利用が観察されています。 中には、取り扱いに注意を要するデータの改ざんに至ったものもあります。
熟練した攻撃者たちは、ますます、 インターネットプロトコルの些細な点を攻略しようとするようになっています。； 異成分から成るインターネットワークにおいて重要な機能であるIPパケットのフラグメンテーションは、 我々がここで解き明かす、いくつかの潜在的な問題点を引き起こします。
ルーター上のIPパケットフィルタは、 管理者にパケットフラグメンテーションを見せないユーザインターフェイスを持つ設計がなされています。； 概念的にはIPフィルタは、完全な形をした各IPパケットに適用されます。
フラグメントフィルタリングについてのひとつのアプローチに、 Mogulによって書かれたもの [1] があり、 最初のフラグメント(FO==0)へのフィルタルールの適用結果の記録をとっておき、 それらを同じパケットの以降のフラグメントに適用するものです。 そのフィルタリングモジュールは、発信元アドレス、宛先のアドレス、 プロトコル、IP IDによってインデックスされたパケットのリストを保持します。 最初(FO==0)のフラグメントが観察され、MFビットがセットされていたら、 リストの要素がフィルタアクセスチェックの結果を保持するために確保されます。 FOが0でないパケットが来たら、 SA/DA/PROT/IDが一致するそのリストの要素を参照し、 その保持された結果(通過もしくはブロック)を適用します。 MFビットが0のフラグメントが観察されたら、リストの要素を解放します。
この手法(あるいは、ある種のこの改良)によって、 あらゆる攻撃パケット全体をうまく除去することができるでしょうが、 これにはいくつかの困難があります。 異なる経路を通ってきたといった理由で順序通りに到着しないフラグメントは、 ひとつの設計上の仮定を壊し、 結果として望まれないフラグメントが漏れてしまう可能性があります。 さらに、そのフィルタリングルータが並列の経路のひとつである場合には、 そのフィルタリングモジュールは、すべてのフラグメントを観ないでしょうし、 ドロップする必要があるパケットについて完全なフラグメントフィルタリングを保証することはできません。
幸い、攻撃パケットのすべてのフラグメントを除去する必要はありません。 「興味ある」パケット情報は先頭にあるヘッダーにあるので、 フィルタは通常、最初のフラグメントだけに適用されます。 最初でないフラグメントは、宛先のホストで最初のフラグメントがない場合、 そのパケットの再構築を完遂することは不可能なので、 フィルタリングされることなく渡り、 それゆえそのパケット全体が捨てられます。 インターネットプロトコルは、パケットのフラグメンテーションを、 データや計算上のオーバーヘッドの理由で非現実的となるまでに小さくすることができてしまいます。 攻撃者は、しばしば典型的なフィルタ機能を攻略し、 さもなければ許されないパケットを密かにフィルタを通すために、 変わったフラグメントシーケンスを作ることができるようになります。 通常の実践においては、 そのような病的なフラグメンテーションは決して使用されないので、 通常のオペレーションを妨げる危険がないよう、 これらのフラグメントをドロップするのが安全です。
多くのIP実装について、 出ていくパケットのフラグメントサイズを非常に小くすることができます。 TCPパケットのTCPヘッダーフィールドの一部が次のフラグメントの中に入るようになるほど、 フラグメントサイズが十分に小さくされた場合には、 それらのフィールドのパターンを決めるフィルタルールは一致しないことでしょう。 フィルタリング実装が最小フラグメントサイズを規定していない場合には、 フィルタに一致しないので、 許されないパケットが通過してしまうかもしれません。
STD 5, RFC 791 によれば：
各インターネットモジュールは、68オクテットのデータグラムを、 これ以上のフラグメンテーションなしに転送できなければなりません。 これは、インターネットヘッダーの上限は60オクテットで、 最小フラグメントは8オクテットだからです。
セキュリティの目的では、 ひとつのフラグメントがIPヘッダーの後ろに少なくとも8オクテットのデータを含んでいることを保証するだけでは十分でないことを覚えておいてください。 それは、重要なトランスポートヘッダー情報(例：TCPヘッダーのCODEフィールド)は、 8番目のデータオクテットより後ろにある可能性があるからです。
この例において最初のフラグメントには、 たった8オクテット(最小フラグメントサイズ)のデータしか含まれていません。 TCPの場合、これは発信元と宛先のポート番号を含むのには十分ですが、 TCPフラグのフィールドは次のフラグメントになってしまいます。
コネクションリクエスト(SYN=1とACK=0をもつTCPデータグラム)をドロップするフィルタは、 最初のオクテットにあるこれらのフラグをテストすることができない可能性があり、 典型的には以降のフラグメントにあるそれらを無視します。
フラグメント 1
IP ヘッダー
+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+
| | ... | Fragment Offset = 0 | ... | |
+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+
TCP ヘッダー
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
フラグメント 2
IP ヘッダー
+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+
| | ... | Fragment Offset = 1 | ... | |
+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+
TCP ヘッダー
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ルーターにおいて、 通過するフラグメントに一定の制限を規定することによって、 要するに最初のフラグメントが、 すべての必須ヘッダー情報を含むのに十分な大きさをもつようにすることによって、 この種の攻撃を防ぐことができます。
「通過した」パケットの最初のフラグメントが、 すべての必要なフィールドを持っていることを保証するためには2つのやり方があり、 ひとつは直接的であり、もうひとつは間接的です。
｢興味ある｣フィールドを含むのに要求されるトランスポートヘッダーの最小の長さ(つまり、 パケットフィルタにとって極めて重要な値)を示すTMINという数字があります。 この長さは、元のフラグメントされていないIPパケットのトランスポートヘッダーの先頭から測られます。
TMINは、関連するトランスポートプロトコルの機能であり、 正しく設定された特定のフィルタの機能でもあることを覚えておいてください。
直接的手法は、 各0オフセットのフラグメント中のトランスポートヘッダーの長さを計算し、 それをTMINと比較するものです。 トランスポートヘッダー長がTMINより短い場合には、 そのフラグメントは捨てられます。 オフセットが0でないフラグメントは、チェックされる必要があります。 それは、0オフセットのフラグメントが捨てられた場合、宛先のホストは、 再構築を完遂することができないからです。 これまでのところ、このようになります。：
if FO=0 and TRANSPORTLEN < tmin then
DROP PACKET
しかしTCP以外では、 通常のトランスポートプロトコルの「興味ある」フィールドはトランスポートヘッダーの最初の8オクテットにあるので、 オフセットが0でないフラグメントに適用することはできません。 それゆえ、この執筆時点では、 TCPパケットだけがタイニーフラグメント攻撃に対して脆弱で、 他のトランスポートプロトコルを運ぶIPパケットに適用する必要はありません。 それゆえ、タイニーフラグメントテストの改良版はこのようになります。：
if FO=0 and PROTOCOL=TCP and TRANSPORTLEN < tmin then
DROP PACKET
しかし、 下記のオーバーラッピングフラグメントについての章で検討するように、 このテストではすべてのフラグメンテーション攻撃をブロックすることはできず、 実際、より一般的なテクニックが使用される場合には不要です。
間接的手法は、 0オフセットのフラグメントの外に「興味ある」ヘッダーフィールドがあるようにするためにTCPパケットがフラグメントされている場合、 FOが1であるフラグメントが存在しなければならないという経験則に依拠します。
逆にFO==1のパケットが観察されたら、 フラグメントセットの中に8オクテットの長さのトランスポートヘッダーをもった0オフセットのフラグメントがあることを示します。 この1オフセットフラグメントを捨てることは、 受け手のホストにおける再構築をブロックし、 上記の直接的手法と同程度に有効です。
現行のIPプロトコル仕様、RFC 791では、新しいフラグメントが、 以前に受け取ったいかなるフラグメントのオーバーラップした部分をも上書きしてしまうことになる、 再構築アルゴリズムについて記述しています。
そのような再構築の実装においては、攻撃者は、 最初の(0オフセットの)フラグメントは無害なデータを含んでいて(それゆえ管理しているパケットフィルタを通過し)、 以降の0でないオフセットをもつパケットが(例えば宛先ポートを) TCPヘッダー情報をオーバーラップして書き換えてしまうような一連のパケットを作成することができてしまいます。 これは0フラグメントオフセットを持っていないので、次のパケットは、 大部分のフィルタ実装を通過してしまうことでしょう。
RFC 815は、 改良版のデータグラム再構築アルゴリズムについて概説していますが、 これ自体は主に再構築過程におけるギャップを埋めることに関するものです。 このRFCは、 オーバーラッピングフラグメントの論点については触れていません。
それゆえ完全に準拠したIP実装が、 オーバーラッピングフラグメント攻撃を受け付けないものであることを保証されているわけではありません。 BSD 4.3の再構築の実装は、 先のフラグメントのデータを後のフラグメントのデータよりも優先するようにすることによって、 これらの攻撃を避ける注意をしています。 しかし、必ずしもすべてのIP実装がオリジナルのBSDコードに基づいているわけではなく、 そのようなものの中には脆弱なものもありそうです。
この例において、フラグメントは、 上記の節で述べた最小サイズの要件を満たすのに十分な大きさです。 このフィルタは、 TCPコネクション要求パケットをドロップするように設定されています。
最初のフラグメントは、例えば、 SYN=0, ACK=1といったフィルタを通過することができる無害な値をもっています。
8オクテットのフラグメントをもった、2番目のフラグメントは、 TCPフラグをもっています。 これは、例えば、 SYN=1, ACK=0といった最初のフラグメントのものとは異なります。 この2番目のフラグメントは0オフセットのフラグメントではないのでチェックされず、 これもまたフィルタを通過します。
RFC 791にあるアルゴリズムを完全に確認する場合、 受け手のホストは「悪い」データが後から着たので、 そのパケットをコネクション要求として再構築します。
フラグメント 1
IP ヘッダー
+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+
| | ... | Fragment Offset = 0 | ... | |
+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+
TCP ヘッダー
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.
.
.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Other data) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
フラグメント 2
IP ヘッダー
+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+
| | ... | Fragment Offset = 1 | ... | |
+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+
TCP ヘッダー
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acknowledgment Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F| |
| Offset| Reserved |R|C|S|S|Y|I| Window |
| | |G|K|H|T|N|N| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.
.
.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (Other data) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
受け手のホストが、 新しいデータが以前に受け取ったデータを上書きしないようにする再構築アルゴリズムを持っている場合、 フラグメント2を先に送信し、フラグメント1を次に送ることによって、 同様の攻撃を遂行することができてしまいます。
オーバーラップセーフな再構築アルゴリズムを使用することを要求する標準はないので、 この攻撃に対するホストの潜在的脆弱性は、極めて大きいといえます。
ルーターのIPフィルタリングコードについて、 より良い戦略を採用することによって、 この「攻撃」をブロックすることができるようになります。 ルーターのフィルタリングモジュールが0オフセットでないフラグメントに最小フラグメントオフセットを指定している場合、 トランスポートヘッダーのフィルタパラメータ部分中のオーバーラップを防ぐことができます。
TCPフラグフィールドが、 0オフセットでないフラグメントに含まれないようにするための最小値は、 TCPの場合、16オクテットです。 TCPフラグメントがFO==1を持っている場合、これは捨てられる必要があります。 それはトランスポートヘッダーに、 たった8オクテットしかスタートさせないからです。 便利なことに、FO==1フラグメントをドロップさせることによって、 前で検討したようにタイニーフラグメント攻撃からも防ぐことができます。
RFC 791は、IPスタックが8バイトのIPデータペイロードを、 それ以上フラグメンテーションせずに転送(8バイトごとのフラグメント)できることを要求します。 IPヘッダーは、最大長が60バイト(オプションを含む)なので、 これはリンク上の最小MTUは、68バイトである必要があることを意味します。
典型的なIPヘッダーは、たった20バイトの長さなので、 48バイトのデータを運ぶことができます。 この世に誰も、FO=1をもったTCPパケットを生成したりはしません。 それは、上述のシステムがIPデータを最小8バイトまでフラグメントさせることと、 60バイトのIPヘッダーを要するからです。
結局、フィルタがタイニーフラグメント攻撃とオーバーラッピングフラグメント攻撃の両方で動作するようにするための一般的なアルゴリズムは、このようになります。：
IF FO=1 and PROTOCOL=TCP
then DROP PACKET
他のトランスポートプロトコルヘッダーにあるフィールドに基づいたフィルタリングが、 ルーターによって提供されている場合には、 ヘッダーの中におけるそれらのフィールドの位置によって最小値は、 より大きい可能性があります。 特に、フィルタリングがトランスポートヘッダーの16オクテット以降のデータについて許されている場合には、 柔軟なユーザインターフェイスと何らかの新しいトランスポートプロトコルのためのフィルタの実装の理由で、 FO==1パケットをドロップするだけでは十分ではないことでしょう。
このメモ全体が、 フラグメントされたIPパケットをフィルタすることについて、 セキュリティの観点からの意味合いに関するものです。
上記の攻撃シナリオは、 1995年5月におけるファイアウォールメーリングリストでの議論から発展しました。 参加者には次の方々がいました。： Darren Reed 氏 、Tom Fitzgerald 氏 、Paul Traina 氏。
| [1] |
Mogul, J., "Simple and Flexible Datagram Access Controls for Unix-based Gateways", Digital Equipment Corporation, 1989年 3月. |
| [2] |
Postel, J., Editor, "Internet Protocol - DARPA Internet Program Protocol Specification", STD 5, RFC 791, USC/Information Sciences Institute, 1981年 9月. |
| [3] |
Postel, J., Editor, "Transmission Control Protocol - DARPA Internet Program Protocol Specification", STD 7, RFC 793, USC/Information Sciences Institute, 1981年 9月. |
| [4] |
Clark, D., "IP Datagram Reassembly Algorithms", RFC 815, MIT Laboratory for Computer Science/Computer Systems and Communications Group, 1982年7月. |
G. Paul Ziemba
Alantec
2115 O'Nel Drive
San Jose, CA 95131
EMail： paul＠alantec.com
Darren Reed
Cybersource
1275A Malvern Rd
Melbourne, Vic 3144
Australia
EMail： darrenr＠cyber.com.au
Paul Traina
cisco Systems, Inc.
170 W. Tasman Dr.
San Jose, CA 95028
EMail： pst＠cisco.com
宮川 寧夫
情報処理振興事業協会
セキュリティセンター
EMail： miyakawa＠ipa.go.jp
Copyright (C) The Internet Society (1995). All Rights Reserved.