home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / rfc / 3 / rfc1858.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  20.0 KB  |  564 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         G. Ziemba
  8. Request for Comments: 1858                                      Alantec
  9. Category: Informational                                         D. Reed
  10.                                                             Cybersource
  11.                                                               P. Traina
  12.                                                           cisco Systems
  13.                                                            October 1995
  14.  
  15.  
  16.            Security Considerations for IP Fragment Filtering
  17.  
  18. Status of This Memo
  19.  
  20.    This memo provides information for the Internet community.  This memo
  21.    does not specify an Internet standard of any kind.  Distribution of
  22.    this memo is unlimited.
  23.  
  24. Abstract
  25.  
  26.    IP fragmentation can be used to disguise TCP packets from IP filters
  27.    used in routers and hosts. This document describes two methods of
  28.    attack as well as remedies to prevent them.
  29.  
  30. 1. Background
  31.  
  32.    System administrators rely on manufacturers of networking equipment
  33.    to provide them with packet filters; these filters are used for
  34.    keeping attackers from accessing private systems and information,
  35.    while permitting friendly agents to transfer data between private
  36.    nets and the Internet.  For this reason, it is important for network
  37.    equipment vendors to anticipate possible attacks against their
  38.    equipment and to implement robust mechanisms to deflect such attacks.
  39.  
  40.    The growth of the global Internet has brought with it an increase in
  41.    "undesirable elements" manifested in antisocial behavior.  Recent
  42.    months have seen the use of novel attacks on Internet hosts, which
  43.    have in some cases led to the compromise of sensitive data.
  44.  
  45.    Increasingly sophisticated attackers have begun to exploit the more
  46.    subtle aspects of the Internet Protocol; fragmentation of IP packets,
  47.    an important feature in heterogeneous internetworks, poses several
  48.    potential problems which we explore here.
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Ziemba, Reed & Traina        Informational                      [Page 1]
  59.  
  60. RFC 1858    Security Considerations - IP Fragment Filtering October 1995
  61.  
  62.  
  63. 2. Filtering IP Fragments
  64.  
  65.    IP packet filters on routers are designed with a user interface that
  66.    hides packet fragmentation from the administrator; conceptually, an
  67.    IP filter is applied to each IP packet as a complete entity.
  68.  
  69.    One approach to fragment filtering, described by Mogul [1], involves
  70.    keeping track of the results of applying filter rules to the first
  71.    fragment (FO==0) and applying them to subsequent fragments of the
  72.    same packet.  The filtering module would maintain a list of packets
  73.    indexed by the source address, destination address, protocol, and IP
  74.    ID.  When the initial (FO==0) fragment is seen, if the MF bit is set,
  75.    a list item would be allocated to hold the result of filter access
  76.    checks.  When packets with a non-zero FO come in, look up the list
  77.    element with a matching SA/DA/PROT/ID and apply the stored result
  78.    (pass or block).  When a fragment with a zero MF bit is seen, free
  79.    the list element.
  80.  
  81.    Although this method (or some refinement of it) might successfully
  82.    remove any trace of the offending whole packet, it has some
  83.    difficulties.  Fragments that arrive out of order, possibly because
  84.    they traveled over different paths, violate one of the design
  85.    assumptions, and undesired fragments can leak through as a result.
  86.    Furthermore, if the filtering router lies on one of several parallel
  87.    paths, the filtering module will not see every fragment and cannot
  88.    guarantee complete fragment filtering in the case of packets that
  89.    should be dropped.
  90.  
  91.  
  92.    Fortunately, we do not need to remove all fragments of an offending
  93.    packet.  Since "interesting" packet information is contained in the
  94.    headers at the beginning, filters are generally applied only to the
  95.    first fragment.  Non-first fragments are passed without filtering,
  96.    because it will be impossible for the destination host to complete
  97.    reassembly of the packet if the first fragment is missing, and
  98.    therefore the entire packet will be discarded.
  99.  
  100.    The Internet Protocol allows fragmentation of packets into pieces so
  101.    small as to be impractical because of data and computational
  102.    overhead.  Attackers can sometimes exploit typical filter behavior
  103.    and the ability to create peculiar fragment sequences in order to
  104.    sneak otherwise disallowed packets past the filter.  In normal
  105.    practice, such pathalogical fragmentation is never used, so it is
  106.    safe to drop these fragments without danger of preventing normal
  107.    operation.
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Ziemba, Reed & Traina        Informational                      [Page 2]
  115.  
  116. RFC 1858    Security Considerations - IP Fragment Filtering October 1995
  117.  
  118.  
  119. 3. Tiny Fragment Attack
  120.  
  121.    With many IP implementations it is possible to impose an unusually
  122.    small fragment size on outgoing packets.  If the fragment size is
  123.    made small enough to force some of a TCP packet's TCP header fields
  124.    into the second fragment, filter rules that specify patterns for
  125.    those fields will not match.  If the filtering implementation does
  126.    not enforce a minimum fragment size, a disallowed packet might be
  127.    passed because it didn't hit a match in the filter.
  128.  
  129.    STD 5, RFC 791 states:
  130.  
  131.       Every internet module must be able to forward a datagram of 68
  132.       octets without further fragmentation.  This is because an internet
  133.       header may be up to 60 octets, and the minimum fragment is 8
  134.       octets.
  135.  
  136.    Note that, for the purpose of security, it is not sufficient to
  137.    merely guarantee that a fragment contains at least 8 octets of data
  138.    beyond the IP header because important transport header information
  139.    (e.g., the CODE field of the TCP header) might be beyond the 8th data
  140.    octet.
  141.  
  142.    3.1 Example of the Tiny Fragment Attack
  143.  
  144.       In this example, the first fragment contains only eight octets of
  145.       data (the minimum fragment size).  In the case of TCP, this is
  146.       sufficient to contain the source and destination port numbers, but
  147.       it will force the TCP flags field into the second fragment.
  148.  
  149.       Filters that attempt to drop connection requests (TCP datagrams
  150.       having SYN=1 and ACK=0) will be unable to test these flags in the
  151.       first octet, and will typically ignore them in subsequent
  152.       fragments.
  153.  
  154.       FRAGMENT 1
  155.  
  156.       IP HEADER
  157.       +-+-+-+     +-+-+-+-+-+-+-+-+-+-+-+     +-+-+-+
  158.       |     | ... | Fragment Offset = 0 | ... |     |
  159.       +-+-+-+     +-+-+-+-+-+-+-+-+-+-+-+     +-+-+-+
  160.  
  161.       TCP HEADER
  162.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  163.       |        Source Port            |       Destination Port        |
  164.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  165.       |                       Sequence Number                         |
  166.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  167.  
  168.  
  169.  
  170. Ziemba, Reed & Traina        Informational                      [Page 3]
  171.  
  172. RFC 1858    Security Considerations - IP Fragment Filtering October 1995
  173.  
  174.  
  175.       FRAGMENT 2
  176.  
  177.       IP HEADER
  178.       +-+-+-+     +-+-+-+-+-+-+-+-+-+-+-+     +-+-+-+
  179.       |     | ... | Fragment Offset = 1 | ... |     |
  180.       +-+-+-+     +-+-+-+-+-+-+-+-+-+-+-+     +-+-+-+
  181.  
  182.       TCP HEADER
  183.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  184.       |                    Acknowledgment Number                      |
  185.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  186.       |  Data |           |U|A|P|R|S|F|                               |
  187.       | Offset| Reserved  |R|C|S|S|Y|I|            Window             |
  188.       |       |           |G|K|H|T|N|N|                               |
  189.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  190.  
  191.    3.2 Prevention of the Tiny Fragment Attack
  192.  
  193.       In a router, one can prevent this sort of attack by enforcing
  194.       certain limits on fragments passing through, namely, that the
  195.       first fragment be large enough to contain all the necessary header
  196.       information.
  197.  
  198.       There are two ways to guarantee that the first fragment of a
  199.       "passed" packet includes all the required fields, one direct, the
  200.       other indirect.
  201.  
  202.       3.2.1 Direct Method
  203.  
  204.          There is some number TMIN which is the minimum length of a
  205.          transport header required to contain "interesting" fields
  206.          (i.e., fields whose values are significant to packet filters).
  207.          This length is measured from the beginning of the transport
  208.          header in the original unfragmented IP packet.
  209.  
  210.          Note that TMIN is a function of the transport protocol involved
  211.          and also of the particular filters currently configured.
  212.  
  213.          The direct method involves computing the length of the
  214.          transport header in each zero-offset fragment and comparing it
  215.          against TMIN.  If the transport header length is less than
  216.          TMIN, the fragment is discarded.  Non-zero-offset fragments
  217.          need not be checked because if the zero-offset fragment is
  218.          discarded, the destination host will be unable to complete
  219.          reassembly.  So far we have:
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Ziemba, Reed & Traina        Informational                      [Page 4]
  227.  
  228. RFC 1858    Security Considerations - IP Fragment Filtering October 1995
  229.  
  230.  
  231.             if FO=0 and TRANSPORTLEN < tmin then
  232.                     DROP PACKET
  233.  
  234.          However, the "interesting" fields of the common transport
  235.          protocols, except TCP, lie in the first eight octets of the
  236.          transport header, so it isn't possible to push them into a
  237.          non-zero-offset fragment. Therefore, as of this writing, only
  238.          TCP packets are vulnerable to tiny-fragment attacks and the
  239.          test need not be applied to IP packets carrying other transport
  240.          protocols.  A better version of the tiny fragment test might
  241.          therefore be:
  242.  
  243.             if FO=0 and PROTOCOL=TCP and TRANSPORTLEN < tmin then
  244.                     DROP PACKET
  245.  
  246.          As discussed in the section on overlapping fragments below,
  247.          however, this test does not block all fragmentation attacks,
  248.          and is in fact unnecessary when a more general technique is
  249.          used.
  250.  
  251.       3.2.2 Indirect Method
  252.  
  253.          The indirect method relies on the observation that when a TCP
  254.          packet is fragmented so as to force "interesting" header fields
  255.          out of the zero-offset fragment, there must exist a fragment
  256.          with FO equal to 1.
  257.  
  258.          If a packet with FO==1 is seen, conversely, it could indicate
  259.          the presence, in the fragment set, of a zero-offset fragment
  260.          with a transport header length of eight octets Discarding this
  261.          one-offset fragment will block reassembly at the receiving host
  262.          and be as effective as the direct method described above.
  263.  
  264. 4. Overlapping Fragment Attack
  265.  
  266.    RFC 791, the current IP protocol specification, describes a
  267.    reassembly algorithm that results in new fragments overwriting any
  268.    overlapped portions of previously-received fragments.
  269.  
  270.    Given such a reassembly implementation, an attacker could construct a
  271.    series of packets in which the lowest (zero-offset) fragment would
  272.    contain innocuous data (and thereby be passed by administrative
  273.    packet filters), and in which some subsequent packet having a non-
  274.    zero offset would overlap TCP header information (destination port,
  275.    for instance) and cause it to be modified.  The second packet would
  276.    be passed through most filter implementations because it does not
  277.    have a zero fragment offset.
  278.  
  279.  
  280.  
  281.  
  282. Ziemba, Reed & Traina        Informational                      [Page 5]
  283.  
  284. RFC 1858    Security Considerations - IP Fragment Filtering October 1995
  285.  
  286.  
  287.    RFC 815 outlines an improved datagram reassembly algorithm, but it
  288.    concerns itself primarily with filling gaps during the reassembly
  289.    process.  This RFC remains mute on the issue of overlapping
  290.    fragments.
  291.  
  292.    Thus, fully-compliant IP implementations are not guaranteed to be
  293.    immune to overlapping-fragment attacks.  The 4.3 BSD reassembly
  294.    implementation takes care to avoid these attacks by forcing data from
  295.    lower-offset fragments to take precedence over data from higher-
  296.    offset fragments.  However, not all IP implementations are based on
  297.    the original BSD code, and it is likely that some of them are
  298.    vulnerable.
  299.  
  300.    4.1 Example of the Overlapping Fragment Attack
  301.  
  302.       In this example, fragments are large enough to satisfy the minimum
  303.       size requirements described in the previous section.  The filter
  304.       is configured to drop TCP connection request packets.
  305.  
  306.       The first fragment contains values, e.g., SYN=0, ACK=1, that
  307.       enable it to pass through the filter unharmed.
  308.  
  309.       The second fragment, with a fragment offset of eight octets,
  310.       contains TCP Flags that differ from those given in the first
  311.       fragment, e.g., SYN=1, ACK=0.  Since this second fragment is not a
  312.       0-offset fragment, it will not be checked, and it, too will pass
  313.       through the filter.
  314.  
  315.       The receiving host, if it conforms fully to the algorithms given
  316.       in RFC 791, will reconstitute the packet as a connection request
  317.       because the "bad" data arrived later.
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Ziemba, Reed & Traina        Informational                      [Page 6]
  339.  
  340. RFC 1858    Security Considerations - IP Fragment Filtering October 1995
  341.  
  342.  
  343.       FRAGMENT 1
  344.  
  345.       IP HEADER
  346.       +-+-+-+     +-+-+-+-+-+-+-+-+-+-+-+     +-+-+-+
  347.       |     | ... | Fragment Offset = 0 | ... |     |
  348.       +-+-+-+     +-+-+-+-+-+-+-+-+-+-+-+     +-+-+-+
  349.  
  350.       TCP HEADER
  351.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  352.       |        Source Port            |       Destination Port        |
  353.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  354.       |                       Sequence Number                         |
  355.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  356.       |                    Acknowledgment Number                      |
  357.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  358.       |  Data |           |U|A|P|R|S|F|                               |
  359.       | Offset| Reserved  |R|C|S|S|Y|I|            Window             |
  360.       |       |           |G|K|H|T|N|N|                               |
  361.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  362.                                    .
  363.                                    .
  364.                                    .
  365.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  366.       |                        (Other data)                           |
  367.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  368.  
  369.  
  370.       FRAGMENT 2
  371.  
  372.       IP HEADER
  373.       +-+-+-+     +-+-+-+-+-+-+-+-+-+-+-+     +-+-+-+
  374.       |     | ... | Fragment Offset = 1 | ... |     |
  375.       +-+-+-+     +-+-+-+-+-+-+-+-+-+-+-+     +-+-+-+
  376.  
  377.       TCP HEADER
  378.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  379.       |                    Acknowledgment Number                      |
  380.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  381.       |  Data |           |U|A|P|R|S|F|                               |
  382.       | Offset| Reserved  |R|C|S|S|Y|I|            Window             |
  383.       |       |           |G|K|H|T|N|N|                               |
  384.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  385.                                    .
  386.                                    .
  387.                                    .
  388.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  389.       |                        (Other data)                           |
  390.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  391.  
  392.  
  393.  
  394. Ziemba, Reed & Traina        Informational                      [Page 7]
  395.  
  396. RFC 1858    Security Considerations - IP Fragment Filtering October 1995
  397.  
  398.  
  399.       If the receiving host has a reassembly algorithm that prevents new
  400.       data from overwriting data received previously, we can send
  401.       Fragment 2 first, followed by Fragment 1, and accomplish the same
  402.       successful attack.
  403.  
  404.    4.2 Prevention of the Overlapping Fragment Attack
  405.  
  406.       Since no standard requires that an overlap-safe reassembly
  407.       algorithm be used, the potential vulnerability of hosts to this
  408.       attack is quite large.
  409.  
  410.       By adopting a better strategy in a router's IP filtering code, one
  411.       can be assured of blocking this "attack".  If the router's
  412.       filtering module enforces a minimum fragment offset for fragments
  413.       that have non-zero offsets, it can prevent overlaps in filter
  414.       parameter regions of the transport headers.
  415.  
  416.       In the case of TCP, this minimum is sixteen octets, to ensure that
  417.       the TCP flags field is never contained in a non-zero-offset
  418.       fragment.  If a TCP fragment has FO==1, it should be discarded
  419.       because it starts only eight octets into the transport header.
  420.       Conveniently, dropping FO==1 fragments also protects against the
  421.       tiny fragment attack, as discussed earlier.
  422.  
  423.       RFC 791 demands that an IP stack must be capable of passing an 8
  424.       byte IP data payload without further fragmentation (fragments sit
  425.       on 8 byte boundaries).  Since an IP header can be up to 60 bytes
  426.       long (including options), this means that the minimum MTU on a
  427.       link should be 68 bytes.
  428.  
  429.       A typical IP header is only 20 bytes long and can therefore carry
  430.       48 bytes of data.  No one in the real world should EVER be
  431.       generating a TCP packet with FO=1, as it would require both that a
  432.       previous system fragmenting IP data down to the 8 byte minimum and
  433.       a 60 byte IP header.
  434.  
  435.       A general algorithm, then, for ensuring that filters work in the
  436.       face of both the tiny fragment attack and the overlapping fragment
  437.       attack is:
  438.  
  439.          IF FO=1 and PROTOCOL=TCP then
  440.                  DROP PACKET
  441.  
  442.       If filtering based on fields in other transport protocol headers
  443.       is provided in a router, the minimum could be greater, depending
  444.       on the position of those fields in the header.  In particular, if
  445.       filtering is permitted on data beyond the sixteenth octet of the
  446.       transport header, either because of a flexible user interface or
  447.  
  448.  
  449.  
  450. Ziemba, Reed & Traina        Informational                      [Page 8]
  451.  
  452. RFC 1858    Security Considerations - IP Fragment Filtering October 1995
  453.  
  454.  
  455.       the implementation of filters for some new transport protocol,
  456.       dropping packets with FO==1 might not be sufficient.
  457.  
  458. 5. Security Considerations
  459.  
  460.    This memo is concerned entirely with the security implications of
  461.    filtering fragmented IP packets.
  462.  
  463. 6. Acknowledgements
  464.  
  465.    The attack scenarios described above grew from discussions that took
  466.    place on the firewalls mailing list during May of 1995.  Participants
  467.    included: Darren Reed <avalon@coombs.anu.edu.au>, Tom Fitzgerald
  468.    <fitz@wang.com>, and Paul Traina <pst@cisco.com>.
  469.  
  470. 7. References
  471.  
  472.    [1] Mogul, J., "Simple and Flexible Datagram Access Controls for
  473.        Unix-based Gateways", Digital Equipment Corporation, March 1989.
  474.  
  475.    [2] Postel, J., Editor, "Internet Protocol - DARPA Internet Program
  476.        Protocol Specification", STD 5, RFC 791, USC/Information Sciences
  477.        Institute, September 1981.
  478.  
  479.    [3] Postel, J., Editor, "Transmission Control Protocol - DARPA
  480.        Internet Program Protocol Specification", STD 7, RFC 793,
  481.        USC/Information Sciences Institute, September 1981.
  482.  
  483.    [4] Clark, D., "IP Datagram Reassembly Algorithms", RFC 815, MIT
  484.        Laboratory for Computer Science/Computer Systems and
  485.        Communications Group, July 1982.
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Ziemba, Reed & Traina        Informational                      [Page 9]
  507.  
  508. RFC 1858    Security Considerations - IP Fragment Filtering October 1995
  509.  
  510.  
  511. Authors' Addresses
  512.  
  513.    G. Paul Ziemba
  514.    Alantec
  515.    2115 O'Nel Drive
  516.    San Jose, CA 95131
  517.  
  518.    EMail: paul@alantec.com
  519.  
  520.  
  521.    Darren Reed
  522.    Cybersource
  523.    1275A Malvern Rd
  524.    Melbourne, Vic 3144
  525.    Australia
  526.  
  527.    EMail: darrenr@cyber.com.au
  528.  
  529.  
  530.    Paul Traina
  531.    cisco Systems, Inc.
  532.    170 W. Tasman Dr.
  533.    San Jose, CA 95028
  534.  
  535.    EMail: pst@cisco.com
  536.  
  537.  
  538.  
  539.  
  540.  
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Ziemba, Reed & Traina        Informational                     [Page 10]
  563.  
  564.