Re: ICMP fragmentation required but DF set problems.

[Ofir Arkin <ofir () SYS-SECURITY COM>]

This is a valid method, and known, to slow down a link between two hosts.

In my paper "ICMP Usage In Scanning" (currently version 2.5) Appendix B:
ICMP "Fragmentation Needed but the Don't Fragment Bit was set" and the Path
MTU Discovery Process (Page 132), I have outlined what should be done
according to RFC 1191, http://www.ietf.org/rfc/rfc1191.txt, by J. Mogul, and
S. Deering. I have also included information about "The TCP MSS (Maximum
Segment Size) Option and PATH MTU Discovery Process".


Host Specifications:
===============
A host must reduce his estimated PMTU for the relevant path when he receives
the ICMP "Fragmentation Needed and the DF bit was set" error message. RFC
1191 does not outline a specific behavior that is expected from the sending
host, because different applications may have different requirements, and
different implementation architectures may favor different strategies [This
leaves a room for this method-OA].

The only required behavior is that a host must attempt to avoid sending more
messages with the same PMTU value in the near future. A host can either
cease setting the Don't Fragment bit in the IP header (and allow
fragmentation by the routers in the way) or reduce the datagram size. The
better strategy would be to lower the message size because fragmentation
will cause more traffic and consume more Internet resources.

A host using the PMTU Discovery process must detect decreases in Path MTU as
fast as possible. A host may detect increases in Path MTU, by sending
datagrams larger than the current estimated PMTU, which will usually be
rejected by some router on the path to a destination since the PMTU usually
will not increase. Since this would generate traffic back to the host, the
check for the increases must be done at infrequent intervals. The RFC
specify that an attempt for detecting an increasment must not be done less
than 10 minutes after a datagram Too Big has been received for the given
destination, or less than 2 minute after a previously successful attempt to
increase.

[This again leave a room for this method. A constant DOS that injects the
packet in the intervals between the checks-OA]

The sending host must know how to handle an ICMP "Fragmentation Needed and
the DF bit was set" error message that was sent by a device who does not
know how to handle the PMTU protocol and does not include the next-hop MTU
in the error message. Several strategies are available:

        The PMTU should be set to the minimum between the currently assumed PMTU
and 576 . The DF bit should not be set in future datagrams for that path.
        Searching for the accurate value for the PMTU for a path. We keep sending
datagrams with the DF bit set with lowered PMTU until we do not receive
errors.

A host must not reduce the estimation of a Path MTU value below 68 bytes.
A host MUST not increase its estimate of the Path MTU in response to the
contents of a Datagram Too Big message.


The TCP MSS (Maximum Segment Size) Option and PATH MTU Discovery Process
=============================================================
The RFC specify that a host that is doing Path MTU Discovery must not send
datagrams larger than 576 bytes unless the receiving host grants him
permission.

When we are establishing a TCP connection both sides announce the maximum
amount of data in one packet that should be sent by the remote system - The
maximum segment size, MSS (if one of the ends does not specify an MSS, it
defaults to 536 - there is no permission from the other end to send more
than this amount). The packet generated would be, normally, 40 bytes larger
than the MSS; 20 bytes for the IP header and 20 bytes for the TCP header.
Most systems announce an MSS that is determined from the MTU on the
interface that the traffic to the remote system passes out from the system
through.

Each side upon receiving the MSS of the other side should not send any
segments larger than the MSS received, regardless of the PMTU. After
receiving the MSS value the Path MTU Discovery process will start to take
affect. We will send our IP packets with the DF bit set allowing us to
recognize points in the path to our destination that cannot process packets
larger as the MSS of the destination host plus 40 bytes. When such an ICMP
error message arrives, we should lower the PMTU to a path (according to the
link MTU field, or if not used, to use the rules regarding the old
implementation) and retransmit. The value of the link MTU cannot be higher
than the MSS of the destination host. When retransmission occurs resulting
from ICMP type 3 code 4 error message, the congestion windows should not
change, but slow start should be initiated. The process continues until we
adjust the correct PMTU of a path (not receiving ICMP error messages from
the intermediate routers) which will allow us to fragment at the TCP layer
which is much more efficient than at the IP layer.


Ofir Arkin
ofir () sys-security com
http://www.sys-security.com
PGP CC2C BE53 12C6 C9F2 87B1 B8C6 0DFA CF2D D360 43FA


-----Original Message-----
From: Bugtraq List [mailto:BUGTRAQ () SECURITYFOCUS COM]On Behalf Of antirez
Sent: Sunday, January 14, 2001 10:16 PM
To: BUGTRAQ () SECURITYFOCUS COM
Subject: ICMP fragmentation required but DF set problems.


Hi all,

The problem I'm exposing is quite obvious, but unfortunatelly
can be used in a very simple way by script kiddies.

SYNOPSIS

  It's possible to slowdown (a lot) connections between two
  arbirary hosts (but at least one with the PMTU discovery enabled)
  using some spoofed TCP/IP packet. Maybe you can do more
  against some TCP/IP stack.

AFFECTED SYSTEMS

  I tryed it a bit against some site, seems that at least Linux
  and some BSD are vulnerable. Anyway it is quite probable
  that almost all the TCP/IP stacks with the PMTU discovery
  enabled are vulnerable.

SOLUTION

  There isn't a clear solution.

CREDITS (!)

  me <antirez () invece org>

DETAILS (When I talk about "the stack" I'm refering to Linux 2.4 TCP/IP
stack)

  The path MTU discovery is used to optimize TCP/IP performances.
  Sorry if you don't know how it works, no flood for readers.
  Anyway the stack takes an hash table with the MTU of other ends. When
  an ICMP frag-req but DF set reaches the stack it perform a look-up
  in the hash table, searching for the old MTU, than look at the
  size of the quoted packet in the ICMP packet, and compute the new MTU
  (strong semplification). The look-up is done using even the TOS
  field, since different TOS may have different routing (I guess is for
this).

  The players:

  A - some host that talks or will talk with the host B
  B - some host that talks or will talk with the host A
  C - the attacker, able to spoof IP packets

  C: sends an ICMP echo request, with some data, the source
     address set to A and the dest address set to B.
  B: creates a new entry in the hash table, if there isn't an old.
  C: sends an ICMP fragmentation needed but DF set, with the source
     address set to A and the dest address set to B,
     quoting the ICMP echo-reply response that we can guess (set the
     right TOS (usually 0x40) if you want that this works).
  B: set the new MTU in relation to the quoted packet total len.

  You may want to send this packets once every second, just to
  avoid expires. Also This may be useful if the MSS TCP option override
  the MTU (it shouldn't, but some implementations may do this),
  otherwise you can send even less spoofed packets.

  Note that shouldn't be useful to quote a packet that was really
  sent in this scenario.

EXPLOIT

  Please, write the exploit just to confirm this, don't ship
  it to lame people. I want not to release my proof-of-concepts
  code.

  That's all, can someone confirm this?

regards,
antirez

--
Salvatore Sanfilippo              |
<antirez () invece org>
http://www.kyuzz.org/antirez      |      PGP: finger
antirez () tella alicom com