As per Relevance of the word security, we have this rfc below:
Network Working Group G.
Request for Comments: 1858
Category: Informational D.
P.
cisco
October 1995
Security Considerations for IP Fragment
Status of This
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
IP fragmentation can be used to disguise TCP packets from IP
used in routers and hosts. This document describes two methods
attack as well as remedies to prevent them
1.
System administrators rely on manufacturers of networking
to provide them with packet filters; these filters are used
keeping attackers from accessing private systems and information
while permitting friendly agents to transfer data between
nets and the Internet. For this reason, it is important for
equipment vendors to anticipate possible attacks against
equipment and to implement robust mechanisms to deflect such attacks
The growth of the global Internet has brought with it an increase
"undesirable elements" manifested in antisocial behavior.
months have seen the use of novel attacks on Internet hosts,
have in some cases led to the compromise of sensitive data
Increasingly sophisticated attackers have begun to exploit the
subtle aspects of the Internet Protocol; fragmentation of IP packets
an important feature in heterogeneous internetworks, poses
potential problems which we explore here
Ziemba, Reed & Traina Informational [Page 1]
RFC 1858 Security Considerations - IP Fragment Filtering October 1995
2. Filtering IP
IP packet filters on routers are designed with a user interface
hides packet fragmentation from the administrator; conceptually,
IP filter is applied to each IP packet as a complete entity
One approach to fragment filtering, described by Mogul [1],
keeping track of the results of applying filter rules to the
fragment (FO==0) and applying them to subsequent fragments of
same packet. The filtering module would maintain a list of
indexed by the source address, destination address, protocol, and
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
checks. When packets with a non-zero FO come in, look up the
element with a matching SA/DA/PROT/ID and apply the stored
(pass or block). When a fragment with a zero MF bit is seen,
the list element
Although this method (or some refinement of it) might
remove any trace of the offending whole packet, it has
difficulties. Fragments that arrive out of order, possibly
they traveled over different paths, violate one of the
assumptions, and undesired fragments can leak through as a result
Furthermore, if the filtering router lies on one of several
paths, the filtering module will not see every fragment and
guarantee complete fragment filtering in the case of packets
should be dropped
Fortunately, we do not need to remove all fragments of an
packet. Since "interesting" packet information is contained in
headers at the beginning, filters are generally applied only to
first fragment. Non-first fragments are passed without filtering
because it will be impossible for the destination host to
reassembly of the packet if the first fragment is missing,
therefore the entire packet will be discarded
The Internet Protocol allows fragmentation of packets into pieces
small as to be impractical because of data and
overhead. Attackers can sometimes exploit typical filter
and the ability to create peculiar fragment sequences in order
sneak otherwise disallowed packets past the filter. In
practice, such pathalogical fragmentation is never used, so it
safe to drop these fragments without danger of preventing
operation
Ziemba, Reed & Traina Informational [Page 2]
RFC 1858 Security Considerations - IP Fragment Filtering October 1995
3. Tiny Fragment
With many IP implementations it is possible to impose an
small fragment size on outgoing packets. If the fragment size
made small enough to force some of a TCP packet's TCP header
into the second fragment, filter rules that specify patterns
those fields will not match. If the filtering implementation
not enforce a minimum fragment size, a disallowed packet might
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
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
merely guarantee that a fragment contains at least 8 octets of
beyond the IP header because important transport header
(e.g., the CODE field of the TCP header) might be beyond the 8th
octet
3.1 Example of the Tiny Fragment
In this example, the first fragment contains only eight octets
data (the minimum fragment size). In the case of TCP, this
sufficient to contain the source and destination port numbers,
it will force the TCP flags field into the second fragment
Filters that attempt to drop connection requests (TCP
having SYN=1 and ACK=0) will be unable to test these flags in
first octet, and will typically ignore them in
fragments
FRAGMENT 1
IP
+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+
| | ... | Fragment Offset = 0 | ... | |
+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+
TCP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Ziemba, Reed & Traina Informational [Page 3]
RFC 1858 Security Considerations - IP Fragment Filtering October 1995
FRAGMENT 2
IP
+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+
| | ... | Fragment Offset = 1 | ... | |
+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+
TCP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
In a router, one can prevent this sort of attack by
certain limits on fragments passing through, namely, that
first fragment be large enough to contain all the necessary
information
There are two ways to guarantee that the first fragment of
"passed" packet includes all the required fields, one direct,
other indirect
3.2.1 Direct
There is some number TMIN which is the minimum length of
transport header required to contain "interesting"
(i.e., fields whose values are significant to packet filters).
This length is measured from the beginning of the
header in the original unfragmented IP packet
Note that TMIN is a function of the transport protocol
and also of the particular filters currently configured
The direct method involves computing the length of
transport header in each zero-offset fragment and comparing
against TMIN. If the transport header length is less
TMIN, the fragment is discarded. Non-zero-offset
need not be checked because if the zero-offset fragment
discarded, the destination host will be unable to
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
DROP
However, the "interesting" fields of the common
protocols, except TCP, lie in the first eight octets of
transport header, so it isn't possible to push them into
non-zero-offset fragment. Therefore, as of this writing,
TCP packets are vulnerable to tiny-fragment attacks and
test need not be applied to IP packets carrying other
protocols. A better version of the tiny fragment test
therefore be
if FO=0 and PROTOCOL=TCP and TRANSPORTLEN < tmin
DROP
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
used
3.2.2 Indirect
The indirect method relies on the observation that when a
packet is fragmented so as to force "interesting" header
out of the zero-offset fragment, there must exist a
with FO equal to 1.
If a packet with FO==1 is seen, conversely, it could
the presence, in the fragment set, of a zero-offset
with a transport header length of eight octets Discarding
one-offset fragment will block reassembly at the receiving
and be as effective as the direct method described above
4. Overlapping Fragment
RFC 791, the current IP protocol specification, describes
reassembly algorithm that results in new fragments overwriting
overlapped portions of previously-received fragments
Given such a reassembly implementation, an attacker could construct
series of packets in which the lowest (zero-offset) fragment
contain innocuous data (and thereby be passed by
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
be passed through most filter implementations because it does
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
concerns itself primarily with filling gaps during the
process. This RFC remains mute on the issue of
fragments
Thus, fully-compliant IP implementations are not guaranteed to
immune to overlapping-fragment attacks. The 4.3 BSD
implementation takes care to avoid these attacks by forcing data
lower-offset fragments to take precedence over data from higher
offset fragments. However, not all IP implementations are based
the original BSD code, and it is likely that some of them
vulnerable
4.1 Example of the Overlapping Fragment
In this example, fragments are large enough to satisfy the
size requirements described in the previous section. The
is configured to drop TCP connection request packets
The first fragment contains values, e.g., SYN=0, ACK=1,
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
fragment, e.g., SYN=1, ACK=0. Since this second fragment is not
0-offset fragment, it will not be checked, and it, too will
through the filter
The receiving host, if it conforms fully to the algorithms
in RFC 791, will reconstitute the packet as a connection
because the "bad" data arrived later
Ziemba, Reed & Traina Informational [Page 6]
RFC 1858 Security Considerations - IP Fragment Filtering October 1995
FRAGMENT 1
IP
+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+
| | ... | Fragment Offset = 0 | ... | |
+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+
TCP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+
| | ... | Fragment Offset = 1 | ... | |
+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+
TCP
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
data from overwriting data received previously, we can
Fragment 2 first, followed by Fragment 1, and accomplish the
successful attack
4.2 Prevention of the Overlapping Fragment
Since no standard requires that an overlap-safe
algorithm be used, the potential vulnerability of hosts to
attack is quite large
By adopting a better strategy in a router's IP filtering code,
can be assured of blocking this "attack". If the router'
filtering module enforces a minimum fragment offset for
that have non-zero offsets, it can prevent overlaps in
parameter regions of the transport headers
In the case of TCP, this minimum is sixteen octets, to ensure
the TCP flags field is never contained in a non-zero-
fragment. If a TCP fragment has FO==1, it should be
because it starts only eight octets into the transport header
Conveniently, dropping FO==1 fragments also protects against
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
on 8 byte boundaries). Since an IP header can be up to 60
long (including options), this means that the minimum MTU on
link should be 68 bytes
A typical IP header is only 20 bytes long and can therefore
48 bytes of data. No one in the real world should EVER
generating a TCP packet with FO=1, as it would require both that
previous system fragmenting IP data down to the 8 byte minimum
a 60 byte IP header
A general algorithm, then, for ensuring that filters work in
face of both the tiny fragment attack and the overlapping
attack is
IF FO=1 and PROTOCOL=TCP
DROP
If filtering based on fields in other transport protocol
is provided in a router, the minimum could be greater,
on the position of those fields in the header. In particular,
filtering is permitted on data beyond the sixteenth octet of
transport header, either because of a flexible user interface
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
This memo is concerned entirely with the security implications
filtering fragmented IP packets
6.
The attack scenarios described above grew from discussions that
place on the firewalls mailing list during May of 1995.
included: Darren Reed , Tom
, and Paul Traina .
7.
[1] Mogul, J., "Simple and Flexible Datagram Access Controls
Unix-based Gateways", Digital Equipment Corporation, March 1989.
[2] Postel, J., Editor, "Internet Protocol - DARPA Internet
Protocol Specification", STD 5, RFC 791, USC/Information
Institute, September 1981.
[3] Postel, J., Editor, "Transmission Control Protocol -
Internet Program Protocol Specification", STD 7, RFC 793,
USC/Information Sciences Institute, September 1981.
[4] Clark, D., "IP Datagram Reassembly Algorithms", RFC 815,
Laboratory for Computer Science/Computer Systems
Communications Group, July 1982.
Ziemba, Reed & Traina Informational [Page 9]
RFC 1858 Security Considerations - IP Fragment Filtering October 1995
Authors'
G. Paul
2115 O'Nel
San Jose, CA 95131
EMail: paul@alantec.
Darren
1275A Malvern
Melbourne, Vic 3144
EMail: darrenr@cyber.com.
Paul
cisco Systems, Inc
170 W. Tasman Dr
San Jose, CA 95028
EMail: pst@cisco.
Ziemba, Reed & Traina Informational [Page 10]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
