Examining ICMP Flaws

An anonymous reader writes "A recent internet-draft pointed out a number of security flaws in the design of the ICMP protocol. Most open source projects and vendors have addressed the flaws to some level, but this interesting article on KernelTrap examines the true extent of the problem, and how so far only OpenBSD has implemented all possible counter-measures. Theo de Raadt is quoted saying, "here we have a 20 year old protocol, a part of the Internet infrastructure that hasn't been touched in 10 years and we were all sure was right, and now is cast in doubt.""

Comments

Re:ICMP flaw #1 on Linux: it's in the kernel

[Anonymous Coward]

Where's the -1 misguided when you need it?

ICMP is in the kernel because it's part of TCP/IP, which wouldn't be hard to remove from a Linux kernel.

Kinda makes all your other services pointless thought, don't it.

http://en.wikipedia.org/wiki/TCP/IP

Re:Cliff's Notes: Start Using TCP Sequence Number

[AndrewStephens]

I cannot speak for the orginal implementors of the network stacks, but it was probably for performance (if they thought about it all). Back in the day, when the summers were warm and music was still good, it was not uncommon for the network stack to take a hefty portion of the processor load just processing packets. Shaving off a few cycles per packet by ignoring part of the spec probably looked like a good idea, especially since people were not as concerned with deliberate attacks back then.

Re:ICMP flaw #1 on Linux: it's in the kernel

[OverCode@work]

Yes... it could be done outside of the kernel. The problem is that it's basically a required component of IP (the two interact closely). IP uses ICMP to report errors, for instance. If ICMP were in a user process, it would have to jump the kernel/user boundary every time, which could become very expensive.

ICMP really isn't a server. It's a protocol for performing odd tasks that don't quite belong inside IP itself but that are more or less essential for it to function. 'ping' is just one of about 16 message types ICMP supports. The others involve routing, destination unreachable messages, source quench ("slow down!"), etc.

I think a better design would be to have the entire networking subsystem in userland.

Incidentally, my current project is writing a tun/tap-based IP stack entirely in C#. It's mostly for fun, but when it's finished it'll be a complete userland networking subsystem. (Current status: decodes and defragments IP packets, starting to implement ICMP.)

-John

Some facts about this

[possible]

Here are some facts about these vulnerabilities in no particular order.

1. These are blind exploits, meaning you do NOT have to be a man-in-the-middle.
2. Sequence number checking is not enough. Therefore Linux has not fully fixed these issues yet. Only OpenBSD has fixed them all, and it must be considered the reference implementation for these fixes. TCP window sizes are fairly large these days. You can EASILY exploit this in a few seconds simply by brute forcing into the window.
3. This is much worse than the TCP reset attacks we read about. Why? Because using these ICMP exploits, you can stall a connection without the application layer ever receiving notification that something is amiss.
4. Why does this matter? BGP. How do people secure BGP these days? They filter TCP packets with a firewall. Or they use tunnels. Guess what? That doesn't protect you from these vulnerabilities, because they use ICMP. Guess what? Home users with firewalls aside, most ISPs do not (and cannot, if they expect the Internet to work) filter ICMP.
5. "Responsible disclosure" is incredibly broken these days and it's getting worse. The vendors have hijacked the process. This is at least the 3rd time Cisco has tried to patent somebody else's security work. NISCC and CERT totally blew it. The IETF blew it AGAIN (remember VRRP?) Gont was asked during his presentation "Knowing what you know, how would you handle the disclosure of these issues if you had to do it over." His answer was, he would just write things up and publish them to Bugtraq without notifying anyone ahead of time. And he's not alone. More and more researchers are anonymously publishing things without notifying the vendors, because they don't want to go through this stuff every time they discover an issue.

Re:Cliff's Notes: Start Using TCP Sequence Number

[ph0enix]

The ICMP error message that's returned contains a chunk of the packet that the message refers to. The recipient of the error message uses this to demultiplex the ICMP error and apply the error to the correct connection. To do this for TCP, it needs the source and destination IP addresss and ports.

The TCP sequence number is also there, but the protocol doesn't require it to be checked.

By an large most protocols are designed to work, not to be secure. This needs to change. The TCPM working group needs to admit that this is a flaw, and change the standard rather than sticking their heads in the sand.

Re:Interesting ICMP exploit

[isometrick]

Save yourself some trouble, check out PingTunnel. :)

Re:Cliff's Notes: Start Using TCP Sequence Number

[ph0enix]

I just ran my sniffer and inspected a icmp echo request. I see the ICMP seq#, there is no TCP header on the packet.

Well duh, ICMP echo request/reply messages are not the ICMP error messages being discussed. From TFA:

There are three ICMP type 3 'destination unreachable' errors that are defined in RFC 1122 as hard errors. Code 2, 'protocol unreachable', code 3, 'port unreachable', and possibly code 4, 'fragmentation needed and don't fragment bit set' are all hard errors that if received can cause a TCP stack to tear down an existing connection.

Well known problems, mitigation long overdue

[matman]

Using spoofed unreach packets to drop TCP sessions has been around for a LONG time - it used to be called a "nuke" (before the Windows OOB attack, "WinNuke", became more widely known). I know that I've heard of the quench spoof attack, but hadn't heard of the path MTU attack, yet. Using ICMP redirect messages to arrange MITM attacks was also an old one, but I don't think that most stacks pay attention to redirect any more.

Here's a post from 1993, for example:
http://groups.google.ca/group/comp.protocols.tcp-i p/browse_thread/thread/439b09e36f4738eb/2eacbab1d4 9e966d?q=icmp+unreach+nuke&rnum=3&hl=en#2eacbab1d4 9e966d
One from 2000:
http://groups.google.ca/group/sol.lists.freebsd.se curity/browse_thread/thread/37d9a0a870080133/711f4 cc20af1a450?q=icmp+quench+spoof&rnum=1&hl=en#711f4 cc20af1a450
One from 2003:
http://groups.google.ca/group/linux.kernel/browse_ thread/thread/e96bd4e594c808d5/3f66eac2a5aa8665?q= icmp+path+mtu+spoof&rnum=2&hl=en#3f66eac2a5aa8665

While these kinds of risks have been known for a long time, there hasn't really been much attempt to mitigate them. Fernando seems to be a little green, initially thinking that he discovered new vulnerabilities, but he's doing the right thing in pressuring for methods of mitigation. It's a hard fight against complacency. Some of the ideas are clever, but it'll take a lot of convincing to change something so low level as ICMP. For how simple ICMP is, it has lots of security issues; it has got to be made more complicated very carefully.

Re:ICMP flaw #1 on Linux: it's in the kernel

[Animats]

Sigh.

As someone who once implemented ICMP (in 1982, before BSD, even), I should say something.

First, ICMP is a layer 3 protocol, like TCP and UDP. ICMP is IP protocol #1; TCP is #6 and UDP is #17.

Second, it's quite feasible to put ICMP in user space. I'm writing this on a QNX system where it's in user space. My 1982 implementation was also in user space, as part of 3COM's UNET. Linux doesn't do it that way, but it's not fundamental that ICMP must be in the kernel. It needs to have a mechanism to pass messages to the other protocols, but that's a local message passing problem. But I'm not going to rehash the ever-growing monolithic kernel issue here.

Third, we knew about many of those vulnerabilities back in the 1980s, but weren't as concerned about them because the Internet was a DoD/NSF operation. Destination Unreachable and Source Quench messages used to be taken more seriously than they are now. Destination Unreachable told you where the network was down, and Source Quench told you where it was congested, basic network management info back then. Today, nobody does network management that way and many TCP stacks don't do much, if anything, with ICMP information. I used to encourage the use of Source Quench for congestion management (see my RFC on this, from 1984), but it's far less appropriate today. Back then, we were concerned about packet loss through transmission errors, a frequent occurence with leased-line synchronous modems. So, when a packet was lost, the question was whether you should retransmit rapidly (appropriate for an error) or slowly (appropriate for congestion). Source Quench could disambiguate that situation. Today, it's assumed that packets are lost almost entirely through congestion, since the lower levels are of much better quality than they used to be.