diff options
Diffstat (limited to 'doc/rfc/rfc1858.txt')
| -rw-r--r-- | doc/rfc/rfc1858.txt | 563 |
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc1858.txt b/doc/rfc/rfc1858.txt new file mode 100644 index 0000000..82e4bfe --- /dev/null +++ b/doc/rfc/rfc1858.txt @@ -0,0 +1,563 @@ + + + + + + +Network Working Group G. Ziemba +Request for Comments: 1858 Alantec +Category: Informational D. Reed + Cybersource + P. Traina + cisco Systems + October 1995 + + + Security Considerations for IP Fragment Filtering + +Status 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 1995 + + +2. 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 1995 + + +3. 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 Attack + + RFC 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 1995 + + + RFC 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 + in RFC 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 or + + + +Ziemba, 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 1995 + + +Authors' 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.com + + + + + + + + + + + + + + + + + + + + + + + + + + +Ziemba, Reed & Traina Informational [Page 10] + |