Network Working Group                                          I. Miller
Request for Comments: 3128                                Singularis Ltd
Updates: 1858                                                  June 2001
Category: Informational
        

Protection Against a Variant of the Tiny Fragment Attack

小さなフラグメント攻撃のバリアントに対する保護

Status of this Memo

本文書の位置付け

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。

Copyright Notice

著作権表示

Copyright (C) The Internet Society (2001). All Rights Reserved.

Copyright（c）The Internet Society（2001）。無断転載を禁じます。

Abstract

概要

This document discusses how RFC 1858 compliant filters can be vulnerable to a variant of the "Tiny Fragment Attack" described in section 3.1 of the RFC. This document describes the attack and recommends corrective action.

このドキュメントでは、RFC 1858準拠のフィルターが、RFCのセクション3.1で説明されている「小さなフラグメント攻撃」のバリアントに対してどのように脆弱であるかについて説明します。このドキュメントは攻撃について説明し、是正措置を推奨します。

1. Introduction

1. はじめに

RFC 1858 provides an excellent description of a class of attack on Internet firewalls and proposes countermeasures. However one of these countmeasures, the "Indirect Method" (section 3.2.2) is vulnerable to a combination of two of the attacks described.

RFC 1858は、インターネットファイアウォールに対する攻撃のクラスの優れた説明を提供し、対策を提案します。ただし、これらのカウント測定の1つである「間接的な方法」（セクション3.2.2）は、説明されている2つの攻撃の組み合わせに対して脆弱です。

The attack combines the features of the "Tiny Fragment Attack" (section 3) and the "Overlapping Fragment Attack" (section 4).

攻撃は、「小さなフラグメント攻撃」（セクション3）と「オーバーラップフラグメント攻撃」（セクション4）の特徴を組み合わせています。

1.1 The scope of the attack

1.1 攻撃の範囲

Where the filtering rules allow incoming connections to a machine AND there other ports which allow only outgoing connections on the same host, the attack allows incoming connections to the supposedly outgoing-only ports.

フィルタリングルールがマシンへの着信接続を可能にし、同じホストの発信接続のみを可能にする他のポートに接続すると、攻撃により、発信のみのポートへの着信接続が可能になります。

Note that only the initial connection message need be fragmented. Once the connection is established further traffic on it is legal. The significance of this weakness will depend on the security policy in force.

最初の接続メッセージのみを断片化する必要があることに注意してください。接続が確立されると、さらにトラフィックが合法です。この弱点の重要性は、有効なセキュリティポリシーに依存します。

2. The Tiny Overlapping Fragment Attack

2. 小さなオーバーラップフラグメント攻撃

The attack typically consists of sending three fragments.

攻撃は通常、3つのフラグメントを送信することで構成されています。

Fragment 1: (Fragment offset = 0; length >= 16) Includes whole header and is entirely legal. Typically it describes a SYN packet initiating a new TCP connection to a port on the target host that is allowed to receive incoming connections. e.g., Incoming connection to port 25 SMTP.

フラグメント1 ：（フラグメントオフセット= 0;長さ> = 16）はヘッダー全体を含み、完全に合法です。通常、着信接続を受信することが許可されているターゲットホストのポートへの新しいTCP接続を開始するSynパケットを記述します。たとえば、ポート25 SMTPへの着信接続。

Fragment 2: (Fragment offset = 0; length = 8) Is only the first 8 bytes and could be legal depending on the other 8-bytes of the header, but is NOT legal combined with the corresponding bytes from Fragment 1. Such a fragment includes only the port numbers and sequence number from the TCP header. Typically this packet replaces the destination port number with a port number on which the destination host that is not allowed to receive incoming connections.

フラグメント2 ：（フラグメントオフセット= 0;長さ= 8）は最初の8バイトのみであり、ヘッダーの他の8バイトに応じて合法である可能性がありますが、フラグメント1からの対応するバイトと合法ではありません。TCPヘッダーのポート番号とシーケンス番号のみが含まれます。通常、このパケットは、宛先ポート番号を、着信接続を受信できない宛先ホストがポート番号に置き換えます。

Fragment 3: (Fragment offset >= 2; length = rest of message) Contains no header and completes the message. (This third fragment is not part of the attack. However Fragment 1 cannot be the complete message or it would be passed up to the application before Fragment 2 arrived so a third fragment is necessary.)

フラグメント3 ：（フラグメントオフセット> = 2;長さ=メッセージの残り）ヘッダーが含まれておらず、メッセージを完成させます。（この3番目のフラグメントは攻撃の一部ではありません。ただし、フラグメント1は完全なメッセージではないか、フラグメント2が到着する前にアプリケーションに渡されるため、3番目のフラグメントが必要です。）

2.1 Example of the attack

2.1 攻撃の例

Consider the following trivial set of rules for incoming packets:

着信パケットのための次の些細なルールセットを検討してください。

   +---+-------+-------+-------+-------+-----------------------+
   | 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          |
   +---+-------+-------+-------+-------+-----------------------+
        

Fragment 1: attacker(1234) -> target(SMTP) Ack=0 This is a new SMTP connection and is permitted by rule 1.

フラグメント1：攻撃者（1234） - >ターゲット（SMTP）ACK = 0これは新しいSMTP接続であり、ルール1で許可されています。

Fragment 2: attacker(1234) -> target(Telnet=23) Ack=absent All fields present conform to rule 2, as it could be the start of an FTP packet.

フラグメント2：攻撃者（1234） - >ターゲット（telnet = 23）ack =存在するすべてのフィールドはルール2に準拠しています。これはFTPパケットの開始である可能性があるためです。

Depending on the precise implementation of the fragment reassembly in the target machine's IP stack, fragment B may overwrite fragment A to produce:-

ターゲットマシンのIPスタックでのフラグメント再組み立ての正確な実装に応じて、フラグメントBはフラグメントAを上書きして生成する場合があります。

      attacker(1234) -> target(Telnet) Ack=0
          (new telnet connection)
        

2.2 The failure of "Indirect Method"

2.2 「間接的な方法」の失敗

The Indirect Method attempts to solve both Tiny Fragment and Overlapping Fragment attacks, solely by rejecting packets with FO=1. However none of the above fragments have FO=1, so none are rejected.

間接的なメソッドは、FO = 1でパケットを拒否することだけで、小さなフラグメントとオーバーラップのフラグメント攻撃の両方を解きようとします。ただし、上記のフラグメントにはfo = 1がないため、拒否されるものはありません。

The failure is clear on careful reading. In section 3.2.2 "Indirect Method", RFC 1858 states:-

慎重に読むと失敗は明らかです。セクション3.2.2「間接的方法」では、RFC 1858状態： -

The indirect method relies on the observation that when a TCP packet is fragmented so as to force "interesting" header fields out of the zero-offset fragment, there must exist a fragment with FO equal to 1.

間接的な方法は、TCPパケットがゼロオフセットフラグメントから「興味深い」ヘッダーフィールドを強制するように断片化された場合、1に等しいFOのフラグメントが存在する必要があるという観察に依存しています。

This is normally true where the fragments are genuine fragments, generally by bona fide software, but it is simply not true that a hacker forging fragments is forced to produce an FO=1 fragment simply because (s)he has produced an 8-byte FO=0 fragment. The vulnerability flows from this false premise.

これは通常、フラグメントが一般的に真正なソフトウェアによって本物のフラグメントである場合に真実ですが、ハッカーの鍛造フラグメントがFO = 1フラグメントを生成することを余儀なくされることは単に真実ではありません。= 0フラグメント。脆弱性は、この誤った前提から流れます。

3. Countermeasures

3. 対策

Whereas apparently very elegant, RFC 1858's Indirect Method is not robust. In addition to blocking FO=1 packets, it is also necessary to block FO=0 that hold less than a complete header.

明らかに非常にエレガントなのは、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

fo = 0およびprotocol = tcpおよびtransportlen <tminの場合、fo = 1およびprotocol = tcpの場合はパケットをドロップし、パケットをドロップします

4. Security Considerations

4. セキュリティに関する考慮事項

This memo is concerned entirely with the security implications of filtering fragmented IP packets.

このメモは、断片化されたIPパケットのフィルタリングのセキュリティへの影響に完全に関係しています。

5. Author's Address

5. 著者の連絡先

Ian Miller Singularis Ltd 32 Stockwell Street Cambridge CB1 3ND UK

Ian Miller Singularis Ltd 32 Stockwell Street Cambridge CB1 3nd UK

   Phone: +44 1223 511943
   EMail: Ian_Miller@singularis.ltd.uk
        

6. Full Copyright Statement

6. 完全な著作権声明

Copyright (C) The Internet Society (2001). All Rights Reserved.

Copyright（c）The Internet Society（2001）。無断転載を禁じます。

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.

このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFCエディター機能の資金は現在、インターネット協会によって提供されています。