rfc1858.txt

来自「<VC++网络游戏建摸与实现>源代码」· 文本 代码 · 共 564 行 · 第 1/2 页


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 <[e-mail]>, Tom Fitzgerald
   <[e-mail]>, and Paul Traina <[e-mail]>.

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: [e-mail]


   Darren Reed
   Cybersource
   1275A Malvern Rd
   Melbourne, Vic 3144
   Australia

   EMail: [e-mail]


   Paul Traina
   cisco Systems, Inc.
   170 W. Tasman Dr.
   San Jose, CA 95028

   EMail: [e-mail]


























Ziemba, Reed & Traina        Informational                     [Page 10]