RE: ICMP attacks against TCP: Conclusions
From: Fernando Gont (fernando_at_gont.com.ar)
Date: Wed, 27 Jul 2005 09:36:02 -0300 To: "Craig Wright" <email@example.com>, "Fernando Gont" <firstname.lastname@example.org>, <email@example.com>
At 07:20 p.m. 26/07/2005, Craig Wright wrote:
No. The attacks are against TCP. You DoS the service by triggering an
action on TCP, based on TCP's reaction to the corresponding ICMP messages.
How did you perform your tests?
>I will assume that you mean ICMP attacks against IP or the host as you
>are attacking the stack even if you are attempting to DoS the service
>I tested this hypothesis last night and the service was not slowed
>enough to be a successful attack
>From: Fernando Gont [mailto:firstname.lastname@example.org]
>Sent: 23 July 2005 11:53
>Subject: ICMP attacks against TCP: Conclusions
>My posts to this list have tried to show how easy it is to perform ICMP
>attacks against TCP.
>The attacks are blind, so the attacker does not need to be a "man in the
>middle" to perform then. The typical number of packets required to
>perform any of these attacks is about 16000 (in many cases, the attacker
>requires fewer packets). This means that even when a 128kbps link, it
>will take the attacker much less than a minute to perform them.
>What are the affected applications?
>Well, the first one that may come to your mind is BGP, but there are
>others. For example:
>* Proxies (either transparent, or not)
>Let's say I don't want my users to access the web site at 192.168.0.1.
>the proxy address is 10.0.0.1, I can run any of the tools as:
>icmp-xxxx -c 10.0.0.1:1024-65535 -s 192.168.0.1:80 -t server
>With this attack, I would be messing with all the clients that are using
>the proxy 10.0.0.1 to access the webserver at 192.168.0.1
>Think about two major e-mail providers. Let's say one is 10.0.0.1, and
>other one is 192.168.0.1. Let's DoS the mail transfers from 10.0.0.1 to
>icmp-xxxx -c 10.0.0.1:1024-65535 -s 192.168.0.1:25 -t client
>Let's also DoS the mail transfers from 192.168.0.1 to 10.0.0.1:
>icmp-xxxx -c 192.168.0.1:1024-65535 -s 10.0.0.1:25 -t client
>NATs will usually make all the hosts in your network use one (or a few)
>address(es) for their TCP connections. By performing the attack against
>IP address of the NAT box trying all the possible port number
>you would be attacking the TCP connections of all the clients behind the
>And the list could continue....
>Even only one attacker with broadband access can perform these attacks,
>Not to mention what could happen if someone had the idea to include
>attack tools in an Internet worm.
>Wasn't this simple? Isn't this something that should be fixed?
>Otherwise, read the draft at
>http://www.gont.com.ar/drafts/icmp-attacks-against-tcp.html , send it to
>your vendor, explain it to them, and ask them to fix their OS.
>Some readers have argued why I try to "sell" my internet-draft again and
>again. The answer is simple: 8 people out of 10 of every discussion I
>had on these issues have misunderstood the problem, and how it should be
>Let's name a few:
>* The TCP MD5 option does not protect you from these attacks
>* IPSec does not protect you from these attacks
>* You cannot filter all ICMP messages
>* Relying on fragmenttion has many potential problems (read Mogul's
>"Fragmentation considered harmful" classic, or the recen Matthis'
>"Fragmentation considered very harmful")
>* The minimum IPv4 MTU is 68. If you ignore ICMP messages that claim
>lower than X (where X>68), then there's a high chance your TCP
>Big vendors' employees making misleading claims to the press have
>not helped to make people patch their systems, or push their vendors to
>Those guys that have started nonsensical discussions about whether this
>new or not have not helped, either. And have not realized that the
>discussion should be whether "this is current", rather than whether
>I have received almost no feedback from "vendors". Unfortunately, they
>don't realize that ICMP is a core protocol, and that discussion on the
>counter-measures is needed for the benefit of us all.
>Last, but not least, the IETF specifications need to address these
>If vendors patch their systems, but the IETF specifications are not
>updated, there's a high chance that there will be brand-new vulnerable
>implementations in the near term.
>Get involved. Discuss the counter-measures. Get your vendor fix the
>problems. And ask *how* they are fixing them (what if they just didn't
>understand, and are not really protecting you, or causing more harm than
>And have the specs address these issues. That's the real and final fix
>(Unless you think you'd enjoy having Darren Reed claim "I heard about
>counter-measures years ago. This is old news" in a few years. :-) )
>e-mail: email@example.com || firstname.lastname@example.org
-- Fernando Gont e-mail: email@example.com || firstname.lastname@example.org