Slashdot Mirror
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.""
In that case... I See More Patches. :-(
Beware: In C++, your friends can see your privates!
The spec calls for a sequence number in the block. Vendors aren't checking it. There are a lot of technical details about how TCP connections can be slowed down by a ICMP attack, but if the vendors checked the sequence number it would make it almost impossible to implement these attacks.
Researcher found the bugs, tried to work with major vendors. Lawyers got involved, turns out Cisco had been working on a fix for years (so they say). Seems like vendors are more concerned about getting credit than fixing the bugs.
Reading between the lines, I take it the major vendors have patched their stacks and life is good. Linux implemented all the fixes for all the errors, but addressing the sequence number should be enough for now.
Makes me wonder: what did the guys writing the code back in the 80s think about the sequence number, anyway? It was obviously there for some reason. I guess because it wasn't part of the "official" spec it was ignored? Shame, that. That was back in the day when people probably didn't think of ICMP being used as a cyber attack vector.
Smart Identification Of Cost Savings, One Key to Program Management
While the patent issue was happening with Cisco, CERT/CC created a mailing list to allow vendors to communicate amongst themselves about the newly discovered vulnerability. "They blamed me for submitting my work," Fernando said in exasperation. "One of Cisco's managers of PSIRT said I was cooperating with terrorists, because a terrorist could have gotten the information in the paper I wrote!"
Of course. We know of problems but we are going to go the Security by Obscurity route and then when the cover is blown we'll claim they are supporting terrorism instead of admitting that we were wrong!
If the terrorism route doesn't work we always have the patent on the issue to sue him with!
Way to fucking go, thanks Cisco!
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
The scary thing is that the parent is talking about ICMP without actually knowing what it is.
You see, this is one of the failures of the moderation system: when someone posts something like this, it seems intelligent because it mentions a lot of familiar things, but overally it's not even making sense. The problem is that moderators work like this:
Argument: check
Clear line of thinking: check
Windows comparison: check
The problem is that this checklist does not include VERIFYING THINGS like what ICMP is. This is how the parent got +5, insightful while it's one of the most misinformed posts i've seen in a while.
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
How the heck did this get modded insightful?
ICMP runs on a different layer than all of the services you mentioned. ICMP is a network layer protocol (like IP and IPv6, also called "layer 3"), and all the protocols you mentioned are application layer (layer 7) protocols. There's no direct comparison to be made to any of the protocols (HTTP, SMB, FTP and NFS) you mentioned.
If you want to compare having ICMP in the kernel to other sinilar protocols, your best argument (if you can call it that) is that we should have *IP*, another layer 3 protocol, "running as an ordinary user process, not root, and especially not as a kernel process." Obviously, IP *is* included in the kernel, for plenty of good reasons. Comparing ICMP to application-layer protocols like HTTP holds no weight whatsoever, unless you're completely ignorant of network fundamentals.
How it got modded to +5 Insightful baffles me. I'd have thought this crowd would have a better handle on the basics.
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
Often when Internet providers disable your cable/DSL/LAN connection for security or billing reasons, they just block TCP and UDP but leave ICMP available. I've observed Georgia Tech's ResNet to do this, and reportedly Adelphia's cable ISP does the same. You can ping to your heart's content, but can't send data.
Except that you can.
A ping packet (ICMP echo request) can have a completely arbitrary payload. You can put any data you want there. You could even tunnel IP inside it. You would have to have to have a friendly server on the outside to receive these packets and forward the contents, but that's easily done.
This trick might also be useful for tunnelling past content filters. I don't think any of them scan ICMP packets.
I'm writing a simple userspace IP stack (gets packets from the tun/tap interface), and I intend to try this out once it's a bit more mature.
-John
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.
i p/browse_thread/thread/439b09e36f4738eb/2eacbab1d4 9e966d?q=icmp+unreach+nuke&rnum=3&hl=en#2eacbab1d4 9e966d e curity/browse_thread/thread/37d9a0a870080133/711f4 cc20af1a450?q=icmp+quench+spoof&rnum=1&hl=en#711f4 cc20af1a450 _ thread/thread/e96bd4e594c808d5/3f66eac2a5aa8665?q= icmp+path+mtu+spoof&rnum=2&hl=en#3f66eac2a5aa8665
Here's a post from 1993, for example:
http://groups.google.ca/group/comp.protocols.tcp-
One from 2000:
http://groups.google.ca/group/sol.lists.freebsd.s
One from 2003:
http://groups.google.ca/group/linux.kernel/browse
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.
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.
I run OpenBSD stable, and some belligerent asshole stays up all night worrying about the best possible response to the latest threats. Sure, I will buy a CD http://openbsd.org/items.html#37.
And Theo, thank you for being a belligerent asshole for the good guys.
do you post just for the hell of posting? Brilliant.
13 million whoo!