[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[stalk:00558] Re: [FYI] RFC 3128 on Protection Against a TinyFragment Attack
- To: security-talk@xxxxxxxxxxxxxxxxxxxx
- Subject: [stalk:00558] Re: [FYI] RFC 3128 on Protection Against a TinyFragment Attack
- From: Yasuo Miyakawa <miyakawa@xxxxxxxxx>
- Date: Sun, 01 Jul 2001 20:25:56 +0900
みやかわです。
とりあえず。
# フラグメントA、B のくだりは原文がバグってるような・・・。
At 午後 12:59 01/06/29 +0900, Yasuo Miyakawa wrote:
>週末に訳そうかな・・・。
--
Network Working Group I. Miller
Request for Comments: 3128 Singularis Ltd
Updates: 1858 2001年 6月
Category: Informational
タイニーフラグメント攻撃の変形に対する防御
(Protection Against a Variant of the Tiny Fragment Attack)
このメモの位置づけ
このメモは、インターネット コミュニティに情報を提供するものです。これは、
いかなるインターネット スタンダードをも定めるものではありません。このメ
モの配布には制限はありません。
著作権表記
Copyright (C) The Internet Society (2001). All Rights Reserved.
概要
この文書は、どのように RFC 1858 準拠フィルタがこの RFC の 3.1 節に記述さ
れている「タイニーフラグメント攻撃」の変形に対して脆弱性を持つ可能性があ
るかを検討しています。 この文書は、この攻撃を記述し、矯正手段をとること
を推奨しています。
1. はじめに
RFC 1858 は、インターネットファイアウォール上の一連の攻撃についての優れ
た記述を提供し、対策を提案しています。 しかしながら、これらの対策のひと
つである、「間接的手法」（3.2.2 節）は、記述されている 2つの攻撃の組み合
わせに対して脆弱性をもちます。
この攻撃は、「タイニーフラグメント攻撃」（3節）と「オーバーラッピング フ
ラグメント攻撃」（4節）の特徴を組み合わせます。
1.1 この攻撃の余地
フィルタリングルールが、マシンに対して入り方向のコネクションを許可してお
り、かつ、同一ホスト上に出方向コネクションのみを許可する他のポートがある
場合、この攻撃は、その出方向のみのポートに対して入り方向コネクションを許
してしまいます。
最初のコネクションメッセージだけがフラグメントされる必要があることを銘記
してください。ひとたびコネクションが確立されると、その上の以降のトラフィ
ックは正規のものとされます。この弱点の重大さは、適用されているセキュリテ
ィポリシーに依存します。
2. タイニーオーバーラッピングフラグメント攻撃
この攻撃は典型的には 3つのフラグメントから成ります。
フラグメント 1: (フラグメント オフセット = 0; 長さ >= 16)
ヘッダー全体を含み、完全に正規なものです。典型的には、標的ホスト上の入り
方向のコネクションを受け取ることが許されているポートに対して新しい TCP
コネクションを開始する SYN パケットを表現します。例、ポート 25 SMTP に対
する入り方向コネクション。
フラグメント 2: (フラグメント オフセット = 0; 長さ = 8)
最初の 8バイトだけであり、ヘッダーの他の 8バイトによっては正規のものたり
えますが、フラグメント 1 からの対応するバイトと組み合わせると正規なもの
ではありません。このようなフラグメントは、TCP ヘッダーからのポート番号と
シーケンス番号だけを含んでいます。典型的には、このパケットは、到達先ポー
ト番号を入り方向コネクションを受け取ることが許可されていないはずの到達先
ホストのポート番号に置き換えます。
フラグメント 3: (フラグメント オフセット >= 2; 長さ = メッセージの残り)
ヘッダーを含まず、メッセージを完結させます。（この 3番目のフラグメントは、
この攻撃の部分ではありません。しかし、フラグメント 1 は、完全なメッセー
ジたりえず、もしくは、フラグメント 2 が到達する前にアプリケーションまで
転送される可能性があるので、それゆえ 3番目のフラグメントは必要不可欠です。
）
2.1 攻撃の例
入り方向パケットについて下記のような平凡な一式のルールを考えます。：
+---+-------+-------+-------+-------+-----------------------+
| No|Action | Source| Dest. | Flags | Purpose |
| | | Port | Port | | |
+===+=======+=======+=======+=======+=======================+
| 1 |Permit | >1023 | SMTP | ANY | Incoming E-mail |
+---+-------+-------+-------+-------+-----------------------+
| 2 |Permit | >1023 | ANY | Ack=1| Existing FTP data |
| | | | | channel connections. |
+---+-------+-------+-------+-------+-----------------------+
| 3 |Deny | ANY | ANY | ANY | Default deny |
+---+-------+-------+-------+-------+-----------------------+
フラグメント 1: 攻撃者(1234) -> 標的(SMTP) Ack=0
これは新しい SMTP コネクションであり、ルール 1 によって許可されます。
フラグメント 2: 攻撃者(1234) -> 標的(Telnet=23) Ack=absent
すべてのフィールドは、 FTP パケットの開始である可能性があるので、ルール
2 への準拠を表現しています。
標的マシンの IP スタック中の精密なフラグメント再構築の実装によっては、フ
ラグメント B は、下記のことを行うためにフラグメント A を上書きすることが
できます。：
攻撃者(1234) -> 標的(Telnet) Ack=0
（新しい telnet コネクション）
2.2 「間接的手法」の失敗
間接的手法は、FO=1 でパケットを拒否することだけによって、タイニーフラグ
メント攻撃とオーバーラッピングフラグメント攻撃の両方を解決しようとしてい
ます。しかし、上記のフラグメントには have FO=1 を持ったものはなく、それ
ゆえ拒否されるものはありません。
注意深く読めば失敗は明らかです。 3.2.2 節「間接的手法」において、RFC
1858 は述べています。：
間接的手法は、0 オフセットのフラグメントの外に「興味ある」ヘッダーフィー
ルドがあるようにするために TCP パケットがフラグメントされている場合、FO
が 1 であるフラグメントが存在しなければならない、という経験則に依拠しま
す。
これは通常、誠意あるソフトウェアによる本物のフラグメントである場合、正し
いといえます。しかし、ハッカーが、8バイトの FO=0 フラグメントを作成して
しまったので FO=1 フラグメントを作成することを強いられている、というのは
単純な誤りです。この脆弱性は、誤った前提から発生しています。
3. 対策
RFC 1858 の間接的手法は、一見とてもエレガントではありますが、頑健ではあ
りません。FO=1 パケットをブロックすることに加えて、不完全なヘッダーを保
持する FO=0 をブロックすることが必要不可欠です。
if FO=0 and PROTOCOL=TCP and TRANSPORTLEN < tmin then
DROP PACKET
if FO=1 and PROTOCOL=TCP then
DROP PACKET
4. セキュリティに関する考慮事項
このメモ全体が、フラグメントされた IP パケットをフィルタすることについて
の、セキュリティの観点からの意味合いに関するものです。
5. 著者のアドレス
Ian Miller
Singularis Ltd
32 Stockwell Street
Cambridge
CB1 3ND UK
Phone: +44 1223 511943
EMail: Ian_Miller@xxxxxxxxxxxxxxxxx
翻訳者
宮川寧夫
IPA セキュリティセンター
EMail: miyakawa@xxxxxxxxx
6. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
FITNESS FOR A PARTICULAR PURPOSE.
謝辞
Funding for the RFC Editor function is currently provided by the
Internet Society.
--
- このメイリングリストに関する質問・問い合せ等は
- <security-talk@xxxxxxxxxx>までお知らせください
--
------------------------------------------------------------------------
まだいる？ 梅雨前線。
http://tenki.infoseek.co.jp/gms_b.html?svx=971122