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
| ||
|
Message-ID: <6.2.0.14.0.20050720054108.047f3128@pop.frh.utn.edu.ar> 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