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.""
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
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.
sheep.horse - does not contain information on sheep or horses.
This should not have been modded up. ICMP is not a service like http or smb, though if your only experience with icmp is ping, it might seem that way. ICMP is a low-level part of the network stack, used internally by TCP/IP, and as such it needs to reside wherever the network stack resides. The entire network stack could be moved to userland, but that is a separate question.
We don't put HTTP servers in the kernel.
I'm sure this will end up redundant but I'm going to comment anyway.
I give you TUX
The whole reason for monolithic kernels like Linux is performance and simplicity. Having to do a context switch for every single packet gets expensive...
Linux IT Consulting and Domino Development in Michigan
RFC 792 dates back sep 1981.
wikipedia
You have been modded up, but this is a pretty uninformed argument. ICMP is part of TCP/IP, which you definitely want in the kernel. I guess it would be possible to put it user space, but performance would be terrible. In any case, user space wouldn't protect against what the article is talking about.
As a matter of fact, people DO put HTTP servers in the kernel. There is more than one Linux in-kernel HTTP server around, and parts of IIS run in kernel on later versions of Windows. If you really, really care about performance (hint: Apache doesn't, its strength is flexibility) then the cost of kernel calls and copying data from user space to kernel space is important.
sheep.horse - does not contain information on sheep or horses.
Putting things in the kernel rather than user space isn't purely a performance decision, which seems to be the logic behind your comment. If that was the case, there'd be a whole lot of things that should be moved to user space, such as the dumb terminal or low speed serial port handling.
A lot of things should be put in user space if they can. When those things are put in the kernel, it is usually because the kernel is a better location than userspace. Sometimes it is for performance, sometimes for other reasons. It is a trade off of course.
UDP relies on ICMP to generate unreachable port messages. Coming up with a setup where the in kernel UDP code calls a userspace ICMP process to generate those messages is more complicated than having ICMP as part of the kernel.
The Internet's nature is peer to peer - 20050301_cs_profs.pdf
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
Nice job RTA dorkface:
"The ICMP flaw is in the design of the protocol, not in any specific implementation."
You listed flaws in implementations, none dealing with a flaw inherent to the ICMP protocol.
"What kind of music do pirates listen to?" -Paul Maud'dib
"Yeeeaaarrrrr n' Bee!!" -Stilgar, Leader of Sietch Tabr
<sigh>
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.
<sigh>
Null route any ASs that still allow spoofed egress. (Welcome to 1998)
My network sure as hell doesn't allow any packets to leave that claim to be from an IP that isn't on our network. Does yours? It shouldn't.
I'm pretty sure our upstreams will blackhole any packets emitted on our fiber that don't belong to our ranges too. Yours should as well (if you are an exception to this rule, you'll know).
After that, it is only a matter of watching the managed switches. They'll alert us to MAC collissions faster than you can say "shallow grave".
See that "Preview" button?
Save yourself some trouble, check out PingTunnel. :)
Well duh, ICMP echo request/reply messages are not the ICMP error messages being discussed. From TFA:
<sigh>
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.
ping is actually an abbreviation, it stands for packet inter-network groper.
Durrrrrr. And what happens when that very important IP datagram can't get through because of a routing issue? ICMP_DEST_UNREACH, thats what.
Get less stupid, then try again. Or are you going to propose that the kernel sit around on its ass waiting for some userspace app to get paged in from the harddrive while its dropping the fucking "low latency" packets on the floor so that it can let you know theres a problem?
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.
Congatulations on post 13 million.5 077&cid=13000000
http://developers.slashdot.org/comments.pl?sid=15
https://www.gnu.org/philosophy/free-sw.html
What you wrote is right on except for the minor quibble that ICMP/TCP/UDP are not all layer 3 protocols.
According to the OSI Model:
Layer 1: Physical
Layer 2: Data Link
Layer 3: Network (IP goes here)
Layer 4: Transmission (TCP goes here)
Layer 5: Session
Layer 6: Presentation
Layer 7: Application
UDP and ICMP are kind of harder to classify, although I've most often seen UDP placed in Layer 4 and ICMP in Layer 3. If you were referring to the TCP/IP network model which better represents TCP/IP (go figure), they still wouldn't be at the same layers.
Layer 4: Application (HTTP)
Layer 3: Transport (TCP, UDP)
Layer 2: Internetwork (IP, ICMP)
Layer 1: Network Access (eg Ethernet)
13,000,000 millionth post
We can do better than this.
Congratulations on having the 13 millionth post!
I'm sorry, but you are completely wrong on every one of your points.
First, you don't need to keep sending packets to continue the DOS. You can degrade connections with the MTU attack with exactly one packet per connection. I.e. you don't need to flood.
Second, these vulnerabilities don't require a botnet to execute or to hide your identity. By their nature you must spoof the source address of your packets so you would be difficult to find anyway.
Next, getting hold and maintaining anonymous control of a botnet is a lot harder than running a script-kiddie tool that implements these attacks.
Finally, fixing these problems makes them go away. They exist independantly of susceptibility to flooding. I still lock my doors despite the fact that a thief can smash my windows.
Probably just a typo, but I wanted to clarify a mistype in your post.
ICMP IS a subset of the Internet Protocol(IP). IP, part of TCP/IP, has an error reporting mechanism for when things get screwed up, it is called ICMP. It doesn't sit on top nor beside IP, it sits inside of it, logically speaking.
Both ICMP, which is consider its own entity at times, but is a subset of IP as a whole, and IP are at layer 3. The Networking layer.
TCP and UDP are layer 4.
microkernels(as mentioned in another post) do exactly this: move as much OUT of the kernel as possible, including the networking (TCP/IP) stack. This isn't a bad idea, necesarily, it gives some advantages that microkernels are all about. If your networking stack gets completely destroyed, it doesn't take down your kernel, etc, etc.
monolithic kernels, like Linux(and most OSes, since they are 'easier' and more commonly accepted design) put more things inside the kernel like the networking stack. Not everything, but more things than a microkernel.
All that being said, even in linux, you could still write an userspace TCP/IP stack and use it, AFAIK. Though things like performance would be an issue.
FYI, I'm a Time Warner employee in Austin, TX.
When we disable a modem for non-payment or virus/spam abuse, we do it through rebooting the modem with a new BIN file. Once done, you will not get an IP address. The modem will still have a 10.net address attached to our network to configure. However, it's not accessible so don't bother wasting your time.
Regardless if you could get online through a disabled modem, don't do it. Theft of cable service (including internet service through our cable) is federal crime. So don't even THINK about getting crafty with your connection that has been explicitly disabled for non-payment.
Life is not for the lazy.
First, while source quench is pretty blind, it isn't much of an issue - it's ignored for TCP and I'm not sure that it's used for UDP either (if it is, few important services use UDP over the internet).
Path MTU spoofing is really just a variation of the ICMP Unreach spoof attack (same ICMP type). Unreach packets need to "quote" the header of the packet that couldn't be delivered - including source (random 1024-65535) and target port numbers - this allows the sending host to know what connection is being affected. In order for the attacked host to accept a spoofed unreach, the unreach needs to quote the right source IP/port and target IP/port. Most of the time, the source IP, and target IP/port are known but the source port could be one in a few thousand. It used to be that, on modem connections, sending thousands of unreach packets took a few minutes, but now it can be done in seconds or less. Now you can even guess the source IP (drop all connections from a network to a server). Thus, now, the attack is essentially (if not technically) blind since you don't have to find the right combo - you just send all combos.