Slashdot Log In
Examining ICMP Flaws
Posted by
samzenpus
on Wed Jul 06, 2005 08:00 PM
from the under-the-microscope dept.
from the under-the-microscope dept.
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.""
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
ICMP... (Score:5, Funny)
Cliff's Notes: Start Using TCP Sequence Number (Score:5, Interesting)
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 [whattofix.com]
Re:Cliff's Notes: Start Using TCP Sequence Number (Score:5, Informative)
Parent
Re:Cliff's Notes: Start Using TCP Sequence Number (Score:3, Insightful)
Re:Cliff's Notes: Start Using TCP Sequence Number (Score:4, Informative)
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 [massiveshill.com] needs to admit that this is a flaw, and change the standard rather than sticking their heads in the sand.
Parent
Re:Cliff's Notes: Start Using TCP Sequence Number (Score:3, Insightful)
Regardless I see greater challenges for ICMP with much more complicated answers needed. Until then I still see old school acl's as the bes
Re:Cliff's Notes: Start Using TCP Sequence Number (Score:4, Informative)
Well duh, ICMP echo request/reply messages are not the ICMP error messages being discussed. From TFA:
Parent
Re:Cliff's Notes: Start Using TCP Sequence Number (Score:3, Informative)
The spec does not require the sequence number be checked (or even mention it), but some OSs check it anyways. Even with the sequence number check, the attack is still not impossible, now just on par with the TCP reset [kerneltrap.org]
RFCs are never modified (Score:4, Interesting)
And "back in the day", if you didn't implement part of an RFC for a protocol you implemented, you got lambasted for it. Search around the net for the early 1908s discussions of the TCP Bakeoffs if you want to see how serious we were about it.
Parent
This is ridiculous! (Score:5, Interesting)
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!
Re:This is ridiculous! (Score:4, Insightful)
Parent
Re:This is ridiculous! (Score:4, Interesting)
He continued to reply thoroughly to all their questions, until two months later when he received an email from Cisco's lawyer claiming that Cisco held a patent on his work. He asked their lawyer for specifics, but they refused to reveal any details.
Fernando went on to point out that from his experience vendors seem to be more concerned about who gets credit for finding a flaw, rather than about actually fixing it. Fernando explained, "Cisco was worried about not giving me credit because they claimed to have been working on the problem for four years. They offered to set up a meeting with some people of Cisco Argentina to show me documentation that would prove they had been working on the Path MTU Discovery attack for more than a year. It didn't happen.
One week prior to the eventual discloser, Fernando received a call from the CTO of Cisco Argentina who asked him for a copy of his resume. "He said he wanted to have a meeting with me, telling me they might have a job for me," Fernando shrugged. "The meeting was delayed a few times, then I never heard from him again. I wouldn't have thought much of it, but I mentioned it to other people and it turns out they'd had similar experiences. It seems this is a common practice for Cisco to offer someone work in the hopes you'll not talk to the media when the security issues are disclosed."
Way to go Cisco!
Parent
Yeah, there's a bunch of this stuff around (Score:3, Insightful)
DHCP has a whole bunch of issues too. For example, what if a DHCP client gets a DHCPACK from some machine? I'll bet that it would just reconfigure itself using the information in the packet. Bam, you've got a man-in-the-middle attack.
Interesting ICMP exploit (Score:5, Interesting)
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
Re:Interesting ICMP exploit (Score:5, Informative)
Parent
Re:Interesting ICMP exploit (Score:3, Interesting)
DON'T DO IT! (Score:4, Informative)
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.
Parent
However,.... (Score:3, Insightful)
Now, with that said, Yeah, it is theft, and it is federal. So, I am sure that s?he will not be using illegally. Or at least, I hope not.
Some facts about this (Score:5, Informative)
Re:Some facts about this (Score:4, Informative)
- These are blind exploits, meaning you do NOT have to be a man-in-the-middle.
- 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.
- 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.
- Why does this matter? BGP. How do people secure BGP these days? They filter TCP packets with a firewall. Or they use tunnels.
This issue has to be considered, but as D. Adams said: Don't panic!If the error receiving system is checking the header of the error generating tcp or udp packet (at least 8 byte have to be contained in the icmp error), the attacker has to guess the source port and - in case if tcp - the tcp sequence number to work blindly.
Again: you have to guess the source port, too. There are very few tcp protocols with predictable source ports nowadays. So it's not 2^32/windowsize but probably (2^16-1024)*2^32/windowsize. Have fun brute forcing that.
True: such an attack would feel more like a network problem than like an attack.
And they secure them by no longer using predictable source ports (many BGP implementations used dest port = source port (179) before).
Parent
Typical science (Score:3, Insightful)
This seems very typical of science in all fields. An unproven theory goes unrebutted for some time untill someone realizes we made a big mistake. The world was once flat remember guys! One thing this should point us to is that no matter how solid something appears, it will always be broken whether it be a theory, a protocol or yes even the fortress known as open bsd *duck* Jokes a side, remember nothing is secure.
Dishes and Cilinders (Score:3, Funny)
Holy timewarp batman! (Score:3, Insightful)
http://www.rs-labs.com/papers/tacticas/ircutils/p
nothing new to see here, move along.
Re:Holy timewarp batman! (Score:3, Insightful)
Well, no. The point is not that there is something new here, but that there isn't. These vulnerabilities are older than the www, but they still haven't been addressed properly. Now, that isn't exactly a new thing either, but it's good to give some attention to it, so that, maybe, they will be addressed soon.
And there are interesting philosophical implications, too. Fundamentally, these messages can be spoofed to cause problems. You get the bad with the good. We prob
Well known problems, mitigation long overdue (Score:5, Informative)
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.
Re:Blind attacks (Score:4, Informative)
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.
Parent
Theo (Score:5, Insightful)
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 [openbsd.org].
And Theo, thank you for being a belligerent asshole for the good guys.
Eyeroll (Score:3, Interesting)
Yes, they're real. Yes, you really can use them to bring non-OpenBSD servers to a halt -- for as long as you keep sending packets.
But think it through: to use those vulnerabilities without getting very busted very fast, you have to have control of a botnet -- a significant anonymous source of packets. If you have control of a botnet, you can DDOS the server to death regardless of whether it has these vulnerabilies -- simply fill the pipe with normal packets.
And guess what? Getting a hold of a botnet is a lot easier than exploiting these vulnerabilities.
So, on a practical level, whats the difference between fixing these particular denial-of-service vulnerabilities and ignoring them? Damned if you do, damned if you don't. Better to spend your time worrying about problems whose solution might actually make a difference.
Re:Eyeroll (Score:4, Informative)
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.
Parent
Can this be used as a feature? (Score:3, Interesting)
I'm thinking, they are attacking me, so I'll attack them back! (Normally, I drop all garbage packets).
The Real Problem With Internet Security (Score:4, Interesting)
This is the biggest problem with large companies. Sure, it is has been pointed out adnausium over the years in various sources -The Mythical Man Month and The Innovators Dilemma being two very good ones. It is too bad that our network is now being ruled by bandits because of it. MS has become everything that it hated about IBM. Cisco has so much hardware out there that IOS has to be tested on everything before a new release. How can it be possible that when FOSS gets updated and corrected quicker? Of course, I work for a large company, and I see how long it takes to get a simple task completed. I'm guessing it has a lot to do with modivation. The open source folks really do believe in their product. For the people working in big companies, it is just a paycheck.
Of course, there's always this possibility [phule.net]
Re:ICMP flaw #1 on Linux: it's in the kernel (Score:4, Informative)
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 [wikipedia.org]
Parent
Re:ICMP flaw #1 on Linux: it's in the kernel (Score:4, Informative)
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.
Parent
Re:ICMP flaw #1 on Linux: it's in the kernel (Score:3, Informative)
Re:ICMP flaw #1 on Linux: it's in the kernel (Score:3, Informative)
I'm sure this will end up redundant but I'm going to comment anyway.
I give you TUX [wikipedia.org]
Re:ICMP flaw #1 on Linux: it's in the kernel (Score:3, Informative)
The whole reason for monolithic kernels like Linux is performance and simplicity. Having to do a context switch for every single packet gets expensive...
Re:ICMP flaw #1 on Linux: it's in the kernel (Score:3, Informative)
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 a
IYAMWETAWDED (Score:3, Funny)
Re:ICMP flaw #1 on Linux: it's in the kernel (Score:5, Insightful)
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.
Parent
Re:ICMP flaw #1 on Linux: it's in the kernel (Score:5, 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.
Parent
Re:ICMP flaw #1 on Linux: it's in the kernel (Score:5, Informative)
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) [ietf.org], 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.
Parent
Because things that need it are in the kernel (Score:3, Informative)
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
Re:ICMP flaw #1 on Linux: it's in the kernel (Score:5, Informative)
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
Parent
Re:Hasn't been touched in 10 years? (Score:3, Informative)
"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.
And now for some real info (Score:3, Informative)
Re:Flaws with ICMP (Score:4, Interesting)
Parent
Re:Flaws with ICMP (Score:4, Interesting)
Parent
Re:Flaws with ICMP (Score:3, Informative)
We can do better than this.
Congratulations on having the 13 millionth post!
Re:Flaws with ICMP (Score:4, Informative)
http://developers.slashdot.org/comments.pl?sid=15
Parent
Re:Flaws with ICMP (Score:4, Funny)
Parent