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.""
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!
Put IP in the kernel, put TCP and UDP in the kernel (also layer 4, but performance intensive), move ICMP out?
smash.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
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
do you post just for the hell of posting? Brilliant.
13 million whoo!
Congratulations on having the 13,000,000 millionth post :)
There should be absolutely no discussion of ICMP without considering the fundamental research carried out by Orfin Arkin. His work should be read by anyone willing to discuss the issue beyond the /. gossiping ...
P.S. ... what the heck is going on with the HTML formatted postings?!?
== With enough Will Power, one could move mountains. With enough Brains, one would just leave them where they are ==
Thing is, none of those "vulnerabilities" matter.
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.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
Then why is it that the OpenBSD implementation of the very same ICMP protocol is claimed to be flawless?
Chuuch. Preach. Tabernacle.
I'm thinking, they are attacking me, so I'll attack them back! (Normally, I drop all garbage packets).
You are being MICROattacked, from various angles, in a SOFT manner.
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
"Well, good luck finding a judge that doesn't run a bestiality site."
The power grid is massively overloaded - especially in the Northeast and California, but Oregon has been blacked-out by single line failures before. As for the Internet, an attack on ICMP might be of academic interest, but it seems to me that they'd simply sever critical fibre. Less stoppable and would take substantially longer to repair.
And if you really DID want to launch a data-driven attack, poisoning the router tables or DNS tables would have a larger impact, last longer and would be much harder to trace than an ICMP flood.
In other words, you are absolutely right that the Cisco manager was playing an emotive card, rather than saying anything of any technological credibility. It is not only an utterly unlikely choice of weapon for such folk (too many alternatives that would have greater impact and would be more likely to work), but there is nothing in this new study that hasn't been known for a long time.
If Cisco has a solution already, but competitors (by and large) don't, then Cisco obviously would have an edge in the market, if there was a panic rush to secure systems. On the other hand, they'd lose that edge if competitors upgraded their software prior to such a rush.
The somewhat unpleasent implication would seem to be that individuals within Cisco were considering launching an ICMP-based attack of their own, to get people to switch to Cisco products. (I doubt Cisco itself would touch such a plan with a 10' barge pole.) Right about now, I'd want to know what kind of stock this manager has in Cisco, what kind of performance bonuses he gets and whether he knows DDoS-er Skript Kiddies. If there are provable means and motive, then I think we know why he was so upset at this becoming public.
Suspicion, regardless of why or what, is just that and nothing more. However, were it to transpire that the manager could have personally profitted from an ICMP-based attack, then I think some serious questions need to get asked very quickly.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
When I worked at CheckPoint, back in 2002, I was project manager for SmartDefence. We integrated protection against the PMTU window size problem into SmartDefence, and we had protection against it ever since version 1 (that is - late 2002). You can set the minimal value a PMTU window can shrink to, with ~300 being the default minimum.
The reason we didn't take credit for discovering this at the time was that I picked it up myself from a side note in one of the security mailing lists. I couldn't find at the time the place this was first published, and I sure as hell won't be able to locate it now, but this is not a newly discovered problem, nor is it non-public. The attention is new, but the problem was known even before.
As I no longer work for CheckPoint, I don't know whether they'll make a media circus from this or not. I don't really care either.
Shachar
As a state gets corrupt, its laws multiply; the most corrupt states have the most numerous laws. (Tacitus, Annales 3:27)
The whole idea behind the RFC system was that the documents, once published, are unchanging. Just like every standard ANSI and ISO publish. There can be and often are documents that revise the protocol, but that's the nature of the standards game and even the ISO does it. Despite common references to ISO standards by number, their proper names are ISO nnnnn:yyyy. For example, SGML is ISO 8879:1986, not ISO 8879, and it has been updated three times since it was issued, by ISO 8879:1986/Cor 1:1996, ISO 8879:1986/Cor 2:1999 and ISO 8879:1986/Amd 1:1988.
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.
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.
Not only that, but unless you *are* MITM, you'll never actually know that you've succeeded. So not only do you have to bruteforce it (which will take a ton of bandwidth) you can't know when to stop - which means that you have to run the entire gamut in order to be sure you're successful.
And if the connection restarts (I believe the timeouts listed were 10 minutes), you've gained absolutely nothing.
If you have the bandwidth to brute force this, you might as well be doing a DDoS.
This issue has to be considered, but as D. Adams said: Don't panic!
Very succintly put.
I guess that means in the US people with cable don't own their own modems?
Cable (CATV provider broadband) modems, true. DSL (phoneline based) modems, usually true.
I think I own my DSL modem. But I'm honestly not sure. The difference is that you CAN get your own DSL modem (as long as your provider / service agreement permits/supports it) a lot easier than you can get your own cable modem. But often, the DSL provider gives you a loaned modem as part of service without an upfront cost.
This isn't all that odd, as CATV equipment has traditionally been cable company equipment for decades. (I can remember simple 1-2 coax splitters and antenna-leads-to-coax dongles on the back of the TV clearly saying "PROPERTY OF CABLE COMPANY -- DO NOT REMOVE".) The set-top box is usually owned by the cable company; though this subsided somewhat with the invention of cable-ready TVs, it is the norm again with the advent of digital cable. (Maybe digital cable will standardize, and we'll start seeing digital-cable-ready TVs someday. But with the number of special features in digital cable [e.g. show listings, on-demand, etc.], this isn't so simple.)
(Subscription satellite TV is a different issue; I don't know how that works, but I'm pretty sure you can get your own satellite reciver, such as the HUMAX combination sat receiver/Tivo device, as long as it is compatible with your satellite provider.)
Of course, a few decades ago, your telephone was loaned to you by the phone company, and you were obligated to give it back to them if it broke or you terminated service. Eventually that changed, of course -- I don't even know if you *can* loan a phone from the average telco anymore.
Terrorists can attack freedom, but only Congress can destroy it.