lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Sat Jul 23 03:46:08 2005
From: fernando at frh.utn.edu.ar (Fernando Gont)
Subject: ICMP attacks against TCP: Conclusions

Folks,

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. If 
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


* Mail
Think about two major e-mail providers. Let's say one is 10.0.0.1, and the 
other one is 192.168.0.1. Let's DoS the mail transfers from 10.0.0.1 to 
192.168.0.1:

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
NATs will usually make all the hosts in your network use one (or a few) IP 
address(es) for their TCP connections. By performing the attack against the 
IP address of the NAT box trying all the possible port number combinations, 
you would be attacking the TCP connections of all the clients behind the NAT.


And the list could continue....

Even only one attacker with broadband access can perform these attacks, as 
discussed above.

Not to mention what could happen if someone had the idea to include these 
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 have 
had on these issues have misunderstood the problem, and how it should be fixed.

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 MTU's 
lower than X (where X>68), then there's a high chance your TCP connections 
may stall


Big vendors' employees making misleading claims to the press have certainly 
not helped to make people patch their systems, or push their vendors to 
produce patches.

Those guys that have started nonsensical discussions about whether this is 
new or not have not helped, either. And have not realized that the 
discussion should be whether "this is current", rather than whether "this 
is new".

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 issues. 
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 
good?).

And have the specs address these issues. That's the real and final fix for 
these issues.

Kindest regards,

--
Fernando Gont
e-mail: fernando@...t.com.ar || fgont@....org





Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ