Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Networking

Examining ICMP Flaws 238

Posted by samzenpus 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.

Examining ICMP Flaws More

Examining ICMP Flaws

Comments Filter:

  • ICMP... (Score:5, Funny)

    by Jugalator ( 259273 ) on Wednesday July 06, 2005 @08:04PM (#12999358) Journal
    In that case... I See More Patches. :-(

  • Cliff's Notes: Start Using TCP Sequence Number (Score:5, Interesting)

    by DanielMarkham ( 765899 ) on Wednesday July 06, 2005 @08:07PM (#12999372) Homepage
    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 [whattofix.com]

    • Re:Cliff's Notes: Start Using TCP Sequence Number (Score:5, Informative)

      by AndrewStephens ( 815287 ) on Wednesday July 06, 2005 @08:18PM (#12999430) Homepage
      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.

    • Re:Cliff's Notes: Start Using TCP Sequence Number (Score:2, Interesting)

      by Anonymous Coward
      There are parts of RFC's that are ignored and parts that people expand upon. This is because an RFC is more like a recommendation than an industry standard (i.e. "request for comment"). If somebody didn't implement part of an RFC, they did not think it was useful at the time. This is reasonable because it probably wasn't. This was the purpose of an RFC. Put the information out there and see how people respond (with code).

      This is the major problem with the RFC system. It was thought at the time to be

      • RFCs are never modified (Score:4, Interesting)

        by JohnQPublic ( 158027 ) on Thursday July 07, 2005 @07:36AM (#13001805)
        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.
    • Help me out here, I seriously want to understand you comment. How can ICMP outlined in RFC792 http://www.ietf.org/rfc/rfc0792.txt?number=792/ [ietf.org] allow for a sequence number when it is designed as an unreliable protocol without a port number or sequence number in the header? I mean unless we rewrite ICMP as a layer four protocol I don't see how we can prevent this?

      • Re:Cliff's Notes: Start Using TCP Sequence Number (Score:4, Informative)

        by ph0enix ( 87965 ) on Wednesday July 06, 2005 @08:58PM (#12999616)
        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 [massiveshill.com] needs to admit that this is a flaw, and change the standard rather than sticking their heads in the sand.
        • I just ran my sniffer and inspected a icmp echo request. I see the ICMP seq#, there is no TCP header on the packet. While I can see this being a potential tool to defend against a barage of ICMP echo replies (or any reply protocol under ICMP) but I still cannot see how it would be a usefull tool in other scenarios, e.g. if I were sending Echo's or Information Requests.

          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)

            by ph0enix ( 87965 ) on Wednesday July 06, 2005 @09:30PM (#12999750)
            I just ran my sniffer and inspected a icmp echo request. I see the ICMP seq#, there is no TCP header on the packet.


            Well duh, ICMP echo request/reply messages are not the ICMP error messages being discussed. From TFA:

            There are three ICMP type 3 'destination unreachable' errors that are defined in RFC 1122 as hard errors. Code 2, 'protocol unreachable', code 3, 'port unreachable', and possibly code 4, 'fragmentation needed and don't fragment bit set' are all hard errors that if received can cause a TCP stack to tear down an existing connection.

    • 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.

      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]

  • This is ridiculous! (Score:5, Interesting)

    by garcia ( 6573 ) * on Wednesday July 06, 2005 @08:10PM (#12999387)
    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!

    • Re:This is ridiculous! (Score:4, Insightful)

      by jrockway ( 229604 ) <jon-nospam@jrock.us> on Wednesday July 06, 2005 @09:02PM (#12999639) Homepage Journal
      Wow. It is about time to stop buying Cisco products. Their idea of security is calling people who help them make it better "terrorists". No fucking thanks.
      • Hmmm... That sounds incredibly suspicisous.

        Quick someone call the Department of Homeland Security! This terrorist is trying to bring down America by not buying American!

        Thought you could get away with it did ya? Well, we're not fooled by your shenanigans, not even for a second, terrorist.

      • ..that a huge company like Cisco, a name that is synonymous with the term 'network,' looks kind of silly not having addressed these issues prior to this disclosure. I can understand their defensive stance- they were clearly caught with their pants down. Just the same, that doesn't make it excusable. My level of respect for Cisco just rocketed down a few notches.

      • Re:This is ridiculous! (Score:4, Interesting)

        by dcam ( 615646 ) <david AT uberconcept DOT com> on Thursday July 07, 2005 @02:37AM (#13000900) Homepage
        That is only half of it, read the full article for the way cisco behaved:

        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!
    • It's really sad to realize that Cisco and other big players at this level think that they are justified in trying to patent such core infrastructure technologies or protocols (fixes).

      If Cisco wants to "Empower the Internet Generation" then they should show a little more old-fashioned Internet Netiquette and proactively share new ideas and address security issues openly with the community rather than cowardly behind lawyer's doors. (Afterall, haven't they too benefited from all the opensource code they've

    • Hmmm. (Score:3, Interesting)

      by jd ( 1658 )
      Seems to me that terrorists are after slightly more spectacular targets than the Internet or the power grid. If they were fine with causing actual economic harm, rather than getting newspaper inches, they could have shut down huge swathes of the US at any time.

      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

  • Google search links (Score:2, Informative)

    by karvind ( 833059 )
    I wasn't really familier with ICMP, so did a quick google. Found couple of good links:

    RFC 792 [faqs.org] dates back sep 1981.

    wikipedia [wikipedia.org]

  • Yeah, there's a bunch of this stuff around (Score:3, Insightful)

    by mveloso ( 325617 ) on Wednesday July 06, 2005 @08:41PM (#12999548)
    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.

    • Fixing the DHCP ACK issue seems like it would require a switch update/upgrade so that the switch doesn't allow traffic to any physical port by any other physical port, except the dhcp server's physical port, until the machine connected to that port gets assigned an IP address, by the DHCP server, in response to the machine's DHCP request.
      • Actually the client is supposed to listen to DHCP responses actively even after it has been assigned an address, so a properly configured switch should simply drop DHCP responses from all machines but the designated DHCP server. All other machines are allowed to make DHCP requests.

        Also, a more conservative switch should simply disable most activities of a port unless an interface is properly configured, indicated by a DHCP response sent to the interface. That way you can't just manually setup any IP addres

  • 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.

  • Interesting ICMP exploit (Score:5, Interesting)

    by OverCode@work ( 196386 ) <overcode@@@gmail...com> on Wednesday July 06, 2005 @08:51PM (#12999593) Homepage
    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

  • Some facts about this (Score:5, Informative)

    by possible ( 123857 ) on Wednesday July 06, 2005 @08:52PM (#12999595)
    Here are some facts about these vulnerabilities in no particular order.
    1. These are blind exploits, meaning you do NOT have to be a man-in-the-middle.
    2. 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.
    3. 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.
    4. Why does this matter? BGP. How do people secure BGP these days? They filter TCP packets with a firewall. Or they use tunnels. Guess what? That doesn't protect you from these vulnerabilities, because they use ICMP. Guess what? Home users with firewalls aside, most ISPs do not (and cannot, if they expect the Internet to work) filter ICMP.
    5. "Responsible disclosure" is incredibly broken these days and it's getting worse. The vendors have hijacked the process. This is at least the 3rd time Cisco has tried to patent somebody else's security work. NISCC and CERT totally blew it. The IETF blew it AGAIN (remember VRRP?) Gont was asked during his presentation "Knowing what you know, how would you handle the disclosure of these issues if you had to do it over." His answer was, he would just write things up and publish them to Bugtraq without notifying anyone ahead of time. And he's not alone. More and more researchers are anonymously publishing things without notifying the vendors, because they don't want to go through this stuff every time they discover an issue.

    • Re:Some facts about this (Score:4, Informative)

      by graf0z ( 464763 ) on Thursday July 07, 2005 @04:32AM (#13001161)
      • These are blind exploits, meaning you do NOT have to be a man-in-the-middle.

        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.

      • 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.

        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.

      • 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.

        True: such an attack would feel more like a network problem than like an attack.

      • Why does this matter? BGP. How do people secure BGP these days? They filter TCP packets with a firewall. Or they use tunnels.

        And they secure them by no longer using predictable source ports (many BGP implementations used dest port = source port (179) before).

      This issue has to be considered, but as D. Adams said: Don't panic!

      /graf0z.

      • Brute forcing... (Score:3, Interesting)

        by schon ( 31600 )
        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.

        An
  • 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

  • Typical science (Score:3, Insightful)

    by pstreck ( 558593 ) * on Wednesday July 06, 2005 @09:21PM (#12999716)
    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 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.

    • 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...
      • The conceptualization of the titan (not god) Atlas bearing a globe on his shoulders is relatively modern - 16th century actually. In classic times he bore the vault of the heavens on his shoulders.
        • Yeah, you are correct. According to Homer, Atlas rested the heavens on pillars, which is rather more practical: "A wave-washed island [Ogygia], a wooded island in the navel of the seas. A goddess has made her dwelling there whose father is Atlas the magician; he knows the depths of all the seas, and he, no other, guards the tall pillars that keep the sky and earth apart." -- Homer, in The Odyssey though according to Apollodorus the heavens was sometimes passed to Hercules: "Prometheus advised Herakles not
    • The world was once flat remember guys!

      That was propoganda of the church, not a scientific theory.

      From the begining of time, there has been ample evidence that the world isn't actually flat, that even the most ignorant observer could pick-up on.

  • Holy timewarp batman! (Score:3, Insightful)

    by NotWulfen ( 219204 ) on Wednesday July 06, 2005 @09:27PM (#12999737) Homepage
    IRC networks have been plagued with ICMP unreachables for years

    http://www.rs-labs.com/papers/tacticas/ircutils/pu ke.html [rs-labs.com]

    nothing new to see here, move along.
    • ``nothing new to see here, move along.''

      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)

    by matman ( 71405 ) on Wednesday July 06, 2005 @09:33PM (#12999770)
    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.

    Here's a post from 1993, for example:
    http://groups.google.ca/group/comp.protocols.tcp-i p/browse_thread/thread/439b09e36f4738eb/2eacbab1d4 9e966d?q=icmp+unreach+nuke&rnum=3&hl=en#2eacbab1d4 9e966d [google.ca]
    One from 2000:
    http://groups.google.ca/group/sol.lists.freebsd.se curity/browse_thread/thread/37d9a0a870080133/711f4 cc20af1a450?q=icmp+quench+spoof&rnum=1&hl=en#711f4 cc20af1a450 [google.ca]
    One from 2003:
    http://groups.google.ca/group/linux.kernel/browse_ thread/thread/e96bd4e594c808d5/3f66eac2a5aa8665?q= icmp+path+mtu+spoof&rnum=2&hl=en#3f66eac2a5aa8665 [google.ca]

    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.
  • 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...

  • Theo (Score:5, Insightful)

    by Anonymous Coward on Wednesday July 06, 2005 @10:15PM (#12999993)
    Theo may be a belligerent asshole, no question. But he is a belligerent asshole working for my side.

    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.

  • There should be absolutely no discussion of ICMP without considering the fundamental research carried out by Orfin Arkin. His work [sys-security.com] 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?!?

  • Eyeroll (Score:3, Interesting)

    by Spazmania ( 174582 ) on Wednesday July 06, 2005 @11:07PM (#13000238) Homepage
    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.

    • Re:Eyeroll (Score:4, Informative)

      by dmiller ( 581 ) <djm.mindrot@org> on Thursday July 07, 2005 @12:05AM (#13000490) Homepage
      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.

      • You can degrade connections with the MTU attack with exactly one packet per connection.

        Just curious here - does the connection *stay* degraded, or does it occasionally try to revert to a less degraded condition in the hopes of getting back to normal?? I know modems step baud rate up and down when there's line noise, and it would seem to make sense for IP to try the same trick. I don't write IP stacks,though, so that may be a completely stupid idea... :)

  • Can this be used as a feature? (Score:3, Interesting)

    by SpaceLifeForm ( 228190 ) on Wednesday July 06, 2005 @11:26PM (#13000337)
    With the BS traffic that comes down the pipe when visiting certain websites, could this actually be used to reduce the unwanted traffic?

    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)

    by grumling ( 94709 ) on Wednesday July 06, 2005 @11:33PM (#13000368) Homepage
    From the article: On the other hand, if it were true, then it would mean that Cisco takes about two years to address these issues. I would be concerned about this if I were one of their customers.

    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]

  • "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

  • I might as well claim credit as well (Score:3, Interesting)

    by Sun ( 104778 ) on Thursday July 07, 2005 @03:28AM (#13001036) Homepage
    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

Slashdot Top Deals

A complex system that works is invariably found to have evolved from a simple system that works.

Close