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.""
Heh.. I read ICMP as "I see 'em pee"
Online Starcraft RPG? At
Dietary fiber is like asynchronous IO-- Non-blocking!
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
"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."
r /article.php/3498286 9 30259&tid=172&tid=7
Where the hell has this moron been?
http://www.enterprisenetworkingplanet.com/netsecu
http://www.ciac.org/ciac/bulletins/h-78.shtml
http://bsd.slashdot.org/article.pl?sid=04/08/28/1
etc., etc., etc...
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!
here I am without my mod points :(
"We don't put HTTP servers in the kernel." Umm, khttpd is pretty much an http server in the kernel. But more on topic, what a pain in the ass it would be to have to install and maintain yet another network server. I'd rather just have it in the kernel personally. If I really had a problem with it, I'd take it out. That's the beauty of Linux.
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
smash.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
okay, am I really confused here, or does this make no sense? Parent, if we should move ICMP to userland, what about TCP and UDP?
Karma: Negative (Mostly affected by dorm trolling)
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.
ICMP isn't.
smash.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
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
If you want to be pedantic about it, ICMP has nothing to do with TCP. It's part of IP only.
RFC 792 dates back sep 1981.
wikipedia
If you only had any klew of the things you are talking about, then you would sound credible. ICMP is part of TCP/IP stack. It is important part of TCP/IP stack as well. If you would read up on IPv6 you will find out why it is important or at least meant to be such.
The only person who is capable of killing my karma, is me, do not even try to help me.
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.
Ummm, am I missing something here? You'd rather have an httpd in the kernel, rather than userland? LOL. Is this is a joke or for real? Hmmm, compile from source, or install a binary pkg then run... OR compile/decompile from kernel, reboot production server, cause grief and down time... Why not just use Windows then??? Seriously! I sure hope you don't manage any servers other than maybe your own at home and that only YOU use, not your gf/wife or any one else for that matter.
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.
Please google TCP/IP, then quiz yourself against your grandmother. If she knows more than you about how networks operate, read more. Once you manage to outwit her you are free to state your apologies here.
The Internet would not function without it. If you take ICMP out of the kernel, you also have to take the rest of the TCP/IP protocol stack out of the kernel.
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.
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
If microsoft fixes it first...I See More Patents.... :-(
:-(
If it's not fixed soon...I See More Pwned b0xen...
I think you could send a redirect via ICMP too, to generate your own man-in-the-middle attack. It's been too long since I've read the RFC.
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.
The entire network stack? I'll give you APS. T maybe. N would be hard (microkernel thinking). DP? How? Each user brings his/her own NIC? Generalize the definition of user process, eh?
Of course I'm thinking of the SSI stack. Not every network stack has to be exactly the same, though they will mirror certain parts (general condened or expanded). At some point you will have to talk to the bare metal and when you do that your kernel (by definition) is in charge.
Why can't people accept that there's a decent tradeoff between security and practicality in all things (cars, t-shirts, houses, and yes, even your beloved computer).
The best companies at managing risk - financial companies like credit companies - recognise this tradeoff. So they carefully make sure that there's a ballance between how hard it is to use a credit card and how hard it is to steal a credit card. Sure they could make unstealable cards - but the difficulty in usability would more than make up for it.
Same for ICMP. For 20 years it had no practical exploits - that's EXCELLENT security, not a security hole. Practically no apartment building or office building has that solid a record.
I thought the minimum Internet MTU was 576 bytes, not 68 bytes. So Path MTU should never result in a decrease of the MTU below 576, otherwise such a low MTU would cause problems with all sorts of other interactions. While 576 might slow things down a little bit, it's not 68 bytes by any means, and it's only about 1/3rd the size of the typical 1500 MTU over Ethernet links. It doesn't seem like the solution described in the article is really necessary, although it probably helps some.
We knew about the problems with ICMP when we first designed applications around it in the mid 80s. But at that time it just was not critical or exposed enough for us to really spend too much time planning workarounds or suggesting changes to the specification.
At that time we really didnt think that there would be such a huge number of users for what we thought was something with a very limited audience.
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
The moderation we need is -1, Criticizes Linux/Apple. Hell, that's what the Flamebait is used for on Apple and Linux articles anyway.
OMG, I am sitting here drunk posting on slashdot thinking about what a fucking loser I am, then I read this comment and laughed so hard my nuts fell off!
"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."
WHAT?! I thought that the GPL was better than the BSD? Our reputation is at stake. Fix! Fix! Fix!
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?
Good luck for your illness, man!
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.
Later,
Phil
Er... performance is *NOT* 'terrible' with a *microkernel* and a decent realtime OS, for implementing network in a non-kernel context.
:)
How do you think various real-time OSes like VxWorks' product (amongst others) do it?
Yes, various folks do the network stack in userland just fine, and without a stunning performance loss.
Note: microkernel != monolithic kernel.
as vulnerable as my sweaty ballsack.
IRC networks have been plagued with ICMP unreachables for years
u ke.html
http://www.rs-labs.com/papers/tacticas/ircutils/p
nothing new to see here, move along.
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.
Surprised that Cisco could have known about an issue for two years and taken that long to deal with it?? hahahahaha.... I'm not saying they knew and shelved it, but if they did know, it doesn't surprise me. Look at any number of other failures they've had over the years.
As for trying to Patent your work, no surprise. They would patent a flea on a dog's back if they could, so would Microsoft and so would any other major company of that size. They patent any and every possible concept they can! They employee firm after firm of lawyers that do nothing but file patents. It's as easy as submitting an idea through a web site and having some other guys approve it and the employee collects $3000 or so bucks up-front. So yeah, if you contact Cisco and give them an idea, that guy or gal you talked to has every incentive to submit your idea as a patent, it's big bucks to him or her!
As for Cisco's PSIRT calling you a terrorist sympathizer or whatever, that's also not surprising. That organization is filled with a lot of people with inflated egos and impressions of themselves and they don't like it when someone is smarter than them.
They're a giant behemoth of a corporation riddled with bureaucracy at every level! I can totally believe that this is exactly what happened as written in the article.
I wonder why everyone thinks of Cisco as a benevolent entity with nothing but good intentions. They're no better than Microsoft in their business practices and their "domination" of the networks we all use.
Anyone who hits a stone wall at Microsoft or Cisco and then is surprised really ought to rexamine his or her "picture" of the world.
Me too! Cheers!!
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?
Fernando was interested in discussing the ideas with his peers, but was concerned about vendors trying to patent his suggested fixes.
Aren't patents lovely for innovation and growth of technology?
Not to be a flame/ass/flaming-ass or whatever...
Most current OSes in common usage on the internet (which is what we are talking about here) do not have this design.
sheep.horse - does not contain information on sheep or horses.
Actually, first the world was dish shaped, then it was cilindrical, but the God Atlas has been carrying a globe on his shoulder for about 2500 years already. The American view of the world as a flat Pizza, is very modern...
Oh well, what the hell...
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.
No, I'd rather run an HTTP server in userland for the very reasons that you mentioned. All I was doing was pointing out that an HTTP server has already been implemented in the kernel. Please do read the post and look at what it says before replying.
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 ==
He never said "it is impossible to implement it in the kernel." He just said "we don't put it in the kernel," 'we' being 99% of all server admins.
--
WHO ATE MY BREAKFAST PANTS?
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)
In response, Golf clap then Cheers
No knowledge required to be a slashdot moderator.
Good post.
Enjoy.
It's just the normal noises in here.
Yeah, this is why OS X and Mach blow as servers. No, really.
Is there anything better than clicking through Microsoft ads on Slashdot?
I think you're a bit misguided here. Why would people be wanting to offload TCP onto special TOE NICs if TCP performance wasn't important (not that I agree with doing that myself) ? TCP's processing overhead is higher than IP's, avoiding context switches for TCP, by putting it in the kernel, is a worth while benefit of putting it in kernel space rather than userspace.
ICMP also would have to be in the kernel even if TCP and UDP weren't. ICMP is used by IP itself, for things such as fragmentation time-out messages, protocol unreachables and PMTU discovery.
People didn't just blindly decide to place these things in the kernel space, there are good and sound reasons why they were put there, and I'm sure they've also been re-evaluated quite often since, with the same conclusion being arrived at evey time. Kernel space is best for performance for things that are very commonly used, and for ensuring that the facility is available to all applications that run on the OS, as well as the mechanisms within the kernel that rely on them (e.g., UDP relying on ICMP).
The Internet's nature is peer to peer - 20050301_cs_profs.pdf
If it is John Nagle behind "animats", then he knows very well what he is talking about.
The Internet's nature is peer to peer - 20050301_cs_profs.pdf
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.
Sorry to pick on you in particular.
Fred
"A fool and his freedom are soon parted"
-RMS
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."
Dude, put your name somewhere that shows up with your posts. Maybe in a throw-away email address?
As it happens, I've already read/downloaded the animats promo material, and I'm not quite in your target audience, but I'm not that far off.
I'm sure you know this at some level, but your name is a positive marketing asset for your company. If you're going to set your slashdot username to be the name of the company and get hits that way, just go the extra step and reap the benefits.
Besides, it'll make it easier for us fogies to adjust our Slashdot friends lists.
ICMP is not sent at the rate that TCP or UDP are.
How about you get less aggressive, and go get laid or something.
smash.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
The minimum TCP Maximum Segment Size is, as you say, 576 bytes (536 B TCP payload + 20 bytes TCP header + 20 bytes IP header).
So if the MSS option isn't used during connection set-up, 576 bytes will be used by default (536-byte segment size).
The minimum IP MTU is 68 bytes (for IPv6 it's 1280 bytes which is why there's a possibility for a Path MTU attack whereby some host sends an ICMP TooBig to the IPv6 tunnel source to force fragmentation -- since ICMP TooBigs can be spoofed...). How to detect false TooBig? How to track the source once detected?
Then how do you explain the incredible performance which QNX Neutrino sports? QNX Neutrino is built around a true microkernel, yet its performance is higher than a skyscraper.
The bits on the bus go on and off... on and off... on and off...
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.
No it isn't. Did you even read the article you linked?
Lars T.
To the guy who modded me down from perfect to terrible Karma - Apple haters still suck
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.
"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."
If "we" were all sure, then maybe the wrong people are working on internet and security. The people designing the internet weren't concerned much with adversarial nodes or any of the other ills we have today, and anybody who thinks that ICMP, routing, etc., are in any way secure is a fool. The only reason it works as well as it does is because in the places that really matter (within a single large provider network infrastructure), there is some centralized control.
But it's the system that's been deployed, everybody has to keep their eyes open for potential problems, and they need to get fixed as they get identified. Most security is being handled at a higher level now anyway (certificates, encryption, signatures, etc.), so that the primary thing we have to worry about resulting from the deficiencies of the underlying network is denial of service.
I don't get it.
We recently had heard in the office over one of the Yellow Machine that's made by Anthology Solutions.
it is not illegal to write the code. It would be useful to see if this hack does work. If so, then it will point out weaknesses in the networks as well as an issue with the protocol.
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.
I prefer the "u" in honour as it seems to be missing these days.
Congrats you just earned yourself a foe. You need to read up on networking, and they maybe, just maybe, you might understand how stupid comparing HTTP, SMB, FTP etc to ICMP.
meh
Run ipsentinel, and configure it to "own" all possible IP addresses i.e. 0/0. It'll break ARP which means nothing will work, unless static ARP entries are configured on the hosts.
The Internet's nature is peer to peer - 20050301_cs_profs.pdf
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
Hosts using PMTU Discovery MUST detect decreases in Path MTU as fast as possible. Hosts MAY detect increases in Path MTU, but because doing so requires sending datagrams larger than the current estimated PMTU, and because the likelihood is that the PMTU will not have increased, this MUST be done at infrequent intervals. An attempt to detect an increase (by sending a datagram larger than the current estimate) MUST NOT be done less than 5 minutes after a Datagram Too Big message has been received for the given destination, or less than 1 minute after a previous, successful attempted increase. We recommend setting these timers at twice their minimum values (10 minutes and 2 minutes, respectively).
The Internet's nature is peer to peer - 20050301_cs_profs.pdf
ICMP was designed during an era when network hosts were not assumed to be hostile. I wouldn't blame them for that.
Mea navis aericumbens anguillis abundat
Say you want to throttle a single IP address worldwide on the entier internet.
2^32 addresses in ten minutes (600s): 7158278 ICMP packets per second
I don't know how large ICMP packets are, but I do know they are relatively tiny, say 64 octets. That would mean you need 436Mo/s. Not an entierly trivial amount of bandwidth for an individual, but spread over a thousand botnet peers it should be doable.
Factor in that an attacker would probably want to block a couple of addresses. For example microsoft.com's or Akamai's DNS servers. Another neat trick would be to tell everybody to throttle bandwidth to some of the intercontinental routers or the 13 root DNS servers.
Hmm, I think the next Microsoft Windows worm might be 'interesting', due to the renewed attention on this flaw.
As a state gets corrupt, its laws multiply; the most corrupt states have the most numerous laws. (Tacitus, Annales 3:27)
There is no flaw in the moderation system as you can see - your parent post is modded down to hell: 20 % insightful (no clue about ICMP), 40 % overrated and 10 % flamebait.
It just takes a few minutes until enough moderators had the chance to see this post.
After a while, your post might be modded as flamebait.
Thats a pretty hash call there, dcam. Sure the parent post was uninformed (even for Slashdot!), but its not like he killed your dog or anything. Anyway, I am sure he is regretting it already, what with the pile-on of negative replies.
sheep.horse - does not contain information on sheep or horses.
My theory is:
COUGH! Ahimmm! Ahhiiiim! Cough!
Here it is: ..... Cough! Ahimmm!
That is my theory, it's all mine. Seriously folks, anybody looking at the ICMP design, if they have the slightest IQ, can see the problems with following unverifiable orders coming in from the ether. Perhaps if there was some way of telling that the ICMP packet came from a gosh-darn white-hat router, or using some common sense instead of just blindly following orders.... Not exactly an Einstein concept.... And don't patents have to be "non-obvious"?
ICMP is layer 3, but TCP and UDP are not. They are layer 4. ICMP and IGMP and ARP and IP(v4 and v6) are all on the same layer, IP and ICMP just happen to rely on each other rather closely.
For what its worth, BSD's TCP/IP implimentation was released in april of 1982, so if you did yours before, it wasn't by much.
I'll try to be more useful than GP:
ICMP is almost completely necessary in the kernel because it is essential to proper operation of the TCP/IP stack (at least, when anything short of a perfect session comes along). Putting it in the userland will not save anyone from the exploits - these are not the kind of exploits that result in code execution (unless somebody *REALLY* messes up), they're just side effects of a near-sighted design. It seemed like a great idea to use the system from-boot clock to time TCP packets, until people realised this reveals your uptime and, if the system does not conform to the 1-per-second requirement, your clock granularity.
There is virtually nothing to gain from moving something as small (yet essential) as ICMP out of the kernel. I very much disapprove of the idea of putting a HTTP server in the kernel, and even an FTP proxy is really pushing it (Linux has both, and the BSDs laugh at this). However, there's no need to support micro-kernel designs by moving everything possible into userland. There are many theoretical reasons why this is the best thing possible, but then in practice it's not worth it.
In short: you won't gain anything moving it into userland, but you stand to lose because of the potential for increased latency or lossage in ICMP errors, which could fly in the face of standards or simply confuse/annoy clients. The security issues are resolved by running OpenBSD or being particularly skilfull with how you use pf (last time I checked, iptables' capabilities for packet manipulation weren't up to scratch).
Sam ty sig.
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.
Read this with a British accent: "Additional research into the potential problems of fragmentation can be found in the 1987 paper "Fragmentation considered harmful" and the more recent "Fragmentation considered very harmful" from 2004."
Does that remind anyone else of a sentence that Douglas Adams would write? They still can't replace my favorite, though - Go To Statement Considered Harmful
Don't be deceived by benchmarks of POSIX apps on microkernels. POSIX, by its design (i.e. synchronous system calls), favours monolithic kernels. Take a look at a system like QNX. It's slightly slower than a monolithic kernel running POSIX apps, but it really screams when you use its native, asynchronous, API. Using the native API, system calls can be queued, so you only need a single switch into kernel space for multiple system calls.
[1] Note: Mach is not a well designed microkernel. Mach is a proof of concept microkernel.
I am TheRaven on Soylent News
The rest of the shit surely came from Cisco US. There's no software patents in Argentina, so probably the patent issue was not a problem of the subsidiary. ;-)
He even states that the 'terrorist' accusation was made by one manager of PSIRT.
And even with the job offer, he didnt say if the other people who had the problem where from Argentina or not.
Disclaimer: Im argentine
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.
Correct me if I'm wrong, but the attacks you linked to were man-in-the-middle, but the attacks of TFA were blind, no need to sniff the connection.
Now, having said that, I will say that I prefer (in theory) the idea of a microkernel (or even a nanokernel like Adeos). Especially a microkernel with multiple OS personalities. It would be great to run multiple copies of Windows, Linux and OS X all on the same box. But right now, that's a pipe dream.
Your point makes my point even stronger. The OP wanted to rip out a very low level piece of the network stack into userland. My point was that doing so was pretty much contrary to the design goals of the Linux kernel, and that, if done right, you'd end up with a microkernel architecture. The fact that a properly done microkernel (like QNX) is so dramatically different than a monolithic kernel like Linux just emphasizes what a crazy idea the OP was.
Can we agree on that? :)
Linux IT Consulting and Domino Development in Michigan
I don't think it is terribly harsh. Frankly, if you are going to write comments about something you know next to nothing about then, I'm not sure I want to read your comments.
I've read two classics on TCP/IP (TCP/IP Illustrated volume 2 - Richard W Stevens and Internetworking with TCP/IP by Douglas E Cromer, I own Comer) and written some sockets code, yet I do not consider myself competant to comment in such an authorative way.
What is more, the comment that was made was so clearly wrong, and demonstrated a complete lack of understanding of the protocols. 5 mintues of googling on the ICMP protocol would have answered the question.
That said, by making someone a foe I effectively give them a -1 modifier. So it is merely a means that I am less likely to see their comments. It is not a statement that I have made them an implacible enemy whom I will hunt down.
meh
I think a better design would be to have the entire networking subsystem in userland.
:-)
/Mark
How about moving something to userland that would cause massive context switching on a server? A wait, you already suggested it. Are you still sane?
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.
Incidentally, my current project is writing a event based peer to peer system. I thought about moving more networking code towards kernel and avoid extensive context switching and too many active threads. A special networking code in the kernel could to do some simple prechecking before waking up userland threads waiting for work. In theory, don't know if a event based networking extension would be liked by the maintainer of the Linux networking kernel code.
However, I really appreciate people who code a TCP/IP stack just for fun! Read Stephen's (if you have not done so far)... I could swear he was on drugs while writing some chapters.