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.
AbstractThis 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 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. The attack combines the features of the "Tiny Fragment Attack" (section 3) and the "Overlapping Fragment Attack" (section 4).
Depending on the precise implementation of the fragment reassembly in the target machine's IP stack, fragment B may overwrite fragment A to produce:- attacker(1234) -> target(Telnet) Ack=0 (new telnet connection) section 3.2.2 "Indirect Method", RFC 1858 states:- 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. 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. 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. if FO=0 and PROTOCOL=TCP and TRANSPORTLEN < tmin then DROP PACKET if FO=1 and PROTOCOL=TCP then DROP PACKET
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.