Movatterモバイル変換

Network Working Group                                         G. ZiembaRequest for Comments: 1858                                      AlantecCategory: Informational                                         D. Reed                                                            Cybersource                                                              P. Traina                                                          cisco Systems                                                           October 1995Security Considerations for IP Fragment FilteringStatus of This Memo   This memo provides information for the Internet community.  This memo   does not specify an Internet standard of any kind.  Distribution of   this memo is unlimited.Abstract   IP fragmentation can be used to disguise TCP packets from IP filters   used in routers and hosts. This document describes two methods of   attack as well as remedies to prevent them.1. Background   System administrators rely on manufacturers of networking equipment   to provide them with packet filters; these filters are used for   keeping attackers from accessing private systems and information,   while permitting friendly agents to transfer data between private   nets and the Internet.  For this reason, it is important for network   equipment vendors to anticipate possible attacks against their   equipment and to implement robust mechanisms to deflect such attacks.   The growth of the global Internet has brought with it an increase in   "undesirable elements" manifested in antisocial behavior.  Recent   months have seen the use of novel attacks on Internet hosts, which   have in some cases led to the compromise of sensitive data.   Increasingly sophisticated attackers have begun to exploit the more   subtle aspects of the Internet Protocol; fragmentation of IP packets,   an important feature in heterogeneous internetworks, poses several   potential problems which we explore here.Ziemba, Reed & Traina        Informational                      [Page 1]

RFC 1858    Security Considerations - IP Fragment Filtering October 19952. Filtering IP Fragments   IP packet filters on routers are designed with a user interface that   hides packet fragmentation from the administrator; conceptually, an   IP filter is applied to each IP packet as a complete entity.   One approach to fragment filtering, described by Mogul [1], involves   keeping track of the results of applying filter rules to the first   fragment (FO==0) and applying them to subsequent fragments of the   same packet.  The filtering module would maintain a list of packets   indexed by the source address, destination address, protocol, and IP   ID.  When the initial (FO==0) fragment is seen, if the MF bit is set,   a list item would be allocated to hold the result of filter access   checks.  When packets with a non-zero FO come in, look up the list   element with a matching SA/DA/PROT/ID and apply the stored result   (pass or block).  When a fragment with a zero MF bit is seen, free   the list element.   Although this method (or some refinement of it) might successfully   remove any trace of the offending whole packet, it has some   difficulties.  Fragments that arrive out of order, possibly because   they traveled over different paths, violate one of the design   assumptions, and undesired fragments can leak through as a result.   Furthermore, if the filtering router lies on one of several parallel   paths, the filtering module will not see every fragment and cannot   guarantee complete fragment filtering in the case of packets that   should be dropped.   Fortunately, we do not need to remove all fragments of an offending   packet.  Since "interesting" packet information is contained in the   headers at the beginning, filters are generally applied only to the   first fragment.  Non-first fragments are passed without filtering,   because it will be impossible for the destination host to complete   reassembly of the packet if the first fragment is missing, and   therefore the entire packet will be discarded.   The Internet Protocol allows fragmentation of packets into pieces so   small as to be impractical because of data and computational   overhead.  Attackers can sometimes exploit typical filter behavior   and the ability to create peculiar fragment sequences in order to   sneak otherwise disallowed packets past the filter.  In normal   practice, such pathalogical fragmentation is never used, so it is   safe to drop these fragments without danger of preventing normal   operation.Ziemba, Reed & Traina        Informational                      [Page 2]

RFC 1858    Security Considerations - IP Fragment Filtering October 19953. Tiny Fragment Attack   With many IP implementations it is possible to impose an unusually   small fragment size on outgoing packets.  If the fragment size is   made small enough to force some of a TCP packet's TCP header fields   into the second fragment, filter rules that specify patterns for   those fields will not match.  If the filtering implementation does   not enforce a minimum fragment size, a disallowed packet might be   passed because it didn't hit a match in the filter.   STD 5,RFC 791 states:      Every internet module must be able to forward a datagram of 68      octets without further fragmentation.  This is because an internet      header may be up to 60 octets, and the minimum fragment is 8      octets.   Note that, for the purpose of security, it is not sufficient to   merely guarantee that a fragment contains at least 8 octets of data   beyond the IP header because important transport header information   (e.g., the CODE field of the TCP header) might be beyond the 8th data   octet.   3.1 Example of the Tiny Fragment Attack      In this example, the first fragment contains only eight octets of      data (the minimum fragment size).  In the case of TCP, this is      sufficient to contain the source and destination port numbers, but      it will force the TCP flags field into the second fragment.      Filters that attempt to drop connection requests (TCP datagrams      having SYN=1 and ACK=0) will be unable to test these flags in the      first octet, and will typically ignore them in subsequent      fragments.      FRAGMENT 1      IP HEADER      +-+-+-+     +-+-+-+-+-+-+-+-+-+-+-+     +-+-+-+      |     | ... | Fragment Offset = 0 | ... |     |      +-+-+-+     +-+-+-+-+-+-+-+-+-+-+-+     +-+-+-+      TCP HEADER      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      |        Source Port            |       Destination Port        |      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      |                       Sequence Number                         |      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Ziemba, Reed & Traina        Informational                      [Page 3]

RFC 1858    Security Considerations - IP Fragment Filtering October 1995      FRAGMENT 2      IP HEADER      +-+-+-+     +-+-+-+-+-+-+-+-+-+-+-+     +-+-+-+      |     | ... | Fragment Offset = 1 | ... |     |      +-+-+-+     +-+-+-+-+-+-+-+-+-+-+-+     +-+-+-+      TCP HEADER      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      |                    Acknowledgment Number                      |      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      |  Data |           |U|A|P|R|S|F|                               |      | Offset| Reserved  |R|C|S|S|Y|I|            Window             |      |       |           |G|K|H|T|N|N|                               |      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   3.2 Prevention of the Tiny Fragment Attack      In a router, one can prevent this sort of attack by enforcing      certain limits on fragments passing through, namely, that the      first fragment be large enough to contain all the necessary header      information.      There are two ways to guarantee that the first fragment of a      "passed" packet includes all the required fields, one direct, the      other indirect.      3.2.1 Direct Method         There is some number TMIN which is the minimum length of a         transport header required to contain "interesting" fields         (i.e., fields whose values are significant to packet filters).         This length is measured from the beginning of the transport         header in the original unfragmented IP packet.         Note that TMIN is a function of the transport protocol involved         and also of the particular filters currently configured.         The direct method involves computing the length of the         transport header in each zero-offset fragment and comparing it         against TMIN.  If the transport header length is less than         TMIN, the fragment is discarded.  Non-zero-offset fragments         need not be checked because if the zero-offset fragment is         discarded, the destination host will be unable to complete         reassembly.  So far we have:Ziemba, Reed & Traina        Informational                      [Page 4]

RFC 1858    Security Considerations - IP Fragment Filtering October 1995            if FO=0 and TRANSPORTLEN < tmin then                    DROP PACKET         However, the "interesting" fields of the common transport         protocols, except TCP, lie in the first eight octets of the         transport header, so it isn't possible to push them into a         non-zero-offset fragment. Therefore, as of this writing, only         TCP packets are vulnerable to tiny-fragment attacks and the         test need not be applied to IP packets carrying other transport         protocols.  A better version of the tiny fragment test might         therefore be:            if FO=0 and PROTOCOL=TCP and TRANSPORTLEN < tmin then                    DROP PACKET         As discussed in the section on overlapping fragments below,         however, this test does not block all fragmentation attacks,         and is in fact unnecessary when a more general technique is         used.      3.2.2 Indirect Method         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.         If a packet with FO==1 is seen, conversely, it could indicate         the presence, in the fragment set, of a zero-offset fragment         with a transport header length of eight octets Discarding this         one-offset fragment will block reassembly at the receiving host         and be as effective as the direct method described above.4. Overlapping Fragment AttackRFC 791, the current IP protocol specification, describes a   reassembly algorithm that results in new fragments overwriting any   overlapped portions of previously-received fragments.   Given such a reassembly implementation, an attacker could construct a   series of packets in which the lowest (zero-offset) fragment would   contain innocuous data (and thereby be passed by administrative   packet filters), and in which some subsequent packet having a non-   zero offset would overlap TCP header information (destination port,   for instance) and cause it to be modified.  The second packet would   be passed through most filter implementations because it does not   have a zero fragment offset.Ziemba, Reed & Traina        Informational                      [Page 5]

RFC 1858    Security Considerations - IP Fragment Filtering October 1995RFC 815 outlines an improved datagram reassembly algorithm, but it   concerns itself primarily with filling gaps during the reassembly   process.  This RFC remains mute on the issue of overlapping   fragments.   Thus, fully-compliant IP implementations are not guaranteed to be   immune to overlapping-fragment attacks.  The 4.3 BSD reassembly   implementation takes care to avoid these attacks by forcing data from   lower-offset fragments to take precedence over data from higher-   offset fragments.  However, not all IP implementations are based on   the original BSD code, and it is likely that some of them are   vulnerable.   4.1 Example of the Overlapping Fragment Attack      In this example, fragments are large enough to satisfy the minimum      size requirements described in the previous section.  The filter      is configured to drop TCP connection request packets.      The first fragment contains values, e.g., SYN=0, ACK=1, that      enable it to pass through the filter unharmed.      The second fragment, with a fragment offset of eight octets,      contains TCP Flags that differ from those given in the first      fragment, e.g., SYN=1, ACK=0.  Since this second fragment is not a      0-offset fragment, it will not be checked, and it, too will pass      through the filter.      The receiving host, if it conforms fully to the algorithms given      inRFC 791, will reconstitute the packet as a connection request      because the "bad" data arrived later.Ziemba, Reed & Traina        Informational                      [Page 6]

RFC 1858    Security Considerations - IP Fragment Filtering October 1995      FRAGMENT 1      IP HEADER      +-+-+-+     +-+-+-+-+-+-+-+-+-+-+-+     +-+-+-+      |     | ... | Fragment Offset = 0 | ... |     |      +-+-+-+     +-+-+-+-+-+-+-+-+-+-+-+     +-+-+-+      TCP HEADER      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      |        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)                           |      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      FRAGMENT 2      IP HEADER      +-+-+-+     +-+-+-+-+-+-+-+-+-+-+-+     +-+-+-+      |     | ... | Fragment Offset = 1 | ... |     |      +-+-+-+     +-+-+-+-+-+-+-+-+-+-+-+     +-+-+-+      TCP HEADER      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      |                    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)                           |      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Ziemba, Reed & Traina        Informational                      [Page 7]

RFC 1858    Security Considerations - IP Fragment Filtering October 1995      If the receiving host has a reassembly algorithm that prevents new      data from overwriting data received previously, we can send      Fragment 2 first, followed by Fragment 1, and accomplish the same      successful attack.   4.2 Prevention of the Overlapping Fragment Attack      Since no standard requires that an overlap-safe reassembly      algorithm be used, the potential vulnerability of hosts to this      attack is quite large.      By adopting a better strategy in a router's IP filtering code, one      can be assured of blocking this "attack".  If the router's      filtering module enforces a minimum fragment offset for fragments      that have non-zero offsets, it can prevent overlaps in filter      parameter regions of the transport headers.      In the case of TCP, this minimum is sixteen octets, to ensure that      the TCP flags field is never contained in a non-zero-offset      fragment.  If a TCP fragment has FO==1, it should be discarded      because it starts only eight octets into the transport header.      Conveniently, dropping FO==1 fragments also protects against the      tiny fragment attack, as discussed earlier.RFC 791 demands that an IP stack must be capable of passing an 8      byte IP data payload without further fragmentation (fragments sit      on 8 byte boundaries).  Since an IP header can be up to 60 bytes      long (including options), this means that the minimum MTU on a      link should be 68 bytes.      A typical IP header is only 20 bytes long and can therefore carry      48 bytes of data.  No one in the real world should EVER be      generating a TCP packet with FO=1, as it would require both that a      previous system fragmenting IP data down to the 8 byte minimum and      a 60 byte IP header.      A general algorithm, then, for ensuring that filters work in the      face of both the tiny fragment attack and the overlapping fragment      attack is:         IF FO=1 and PROTOCOL=TCP then                 DROP PACKET      If filtering based on fields in other transport protocol headers      is provided in a router, the minimum could be greater, depending      on the position of those fields in the header.  In particular, if      filtering is permitted on data beyond the sixteenth octet of the      transport header, either because of a flexible user interface orZiemba, Reed & Traina        Informational                      [Page 8]

RFC 1858    Security Considerations - IP Fragment Filtering October 1995      the implementation of filters for some new transport protocol,      dropping packets with FO==1 might not be sufficient.5. Security Considerations   This memo is concerned entirely with the security implications of   filtering fragmented IP packets.6. Acknowledgements   The attack scenarios described above grew from discussions that took   place on the firewalls mailing list during May of 1995.  Participants   included: Darren Reed <avalon@coombs.anu.edu.au>, Tom Fitzgerald   <fitz@wang.com>, and Paul Traina <pst@cisco.com>.7. References   [1] Mogul, J., "Simple and Flexible Datagram Access Controls for       Unix-based Gateways", Digital Equipment Corporation, March 1989.   [2] Postel, J., Editor, "Internet Protocol - DARPA Internet Program       Protocol Specification", STD 5,RFC 791, USC/Information Sciences       Institute, September 1981.   [3] Postel, J., Editor, "Transmission Control Protocol - DARPA       Internet Program Protocol Specification", STD 7,RFC 793,       USC/Information Sciences Institute, September 1981.   [4] Clark, D., "IP Datagram Reassembly Algorithms",RFC 815, MIT       Laboratory for Computer Science/Computer Systems and       Communications Group, July 1982.Ziemba, Reed & Traina        Informational                      [Page 9]

RFC 1858    Security Considerations - IP Fragment Filtering October 1995Authors' Addresses   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.comZiemba, Reed & Traina        Informational                     [Page 10]