Slashdot Mirror


Secret Repairs Preceded TCP Flaw Release

efranco cuts and pastes: "Only the math had changed. But the emergence of a workable exploit for an old TCP security hole prompted a secret initiative to fix the Internet, giving network operators a week to secure vulnerable routers. The clandestine repair effort livened an already intense period for security pros already juggling a bevy of Windows security patches." We ran a story on a this a few days ago.

43 of 204 comments (clear)

  1. Cisco Fix by thebra · · Score: 5, Informative

    is here as posted from an article on the register.

    1. Re:Cisco Fix by robslimo · · Score: 5, Interesting

      When the previous /. story was posted about the TCP flaw, I checked out the NANOG mailing list.

      There was plenty of discussion about it, including various vendor issues (Cisco and Juniper) & fixes, as well as some ISPs dragging their feet on implementing MD5 over peer links. I could tell from some of the things mentioned there that they (the network ops) had advance knowledge of the vulnerability.

      Most interesting was this about looking glasses being too free with info that would allow a TCP reset in one try.

  2. Looks like this is the way it's gonna be... by pointbeing · · Score: 5, Insightful
    These days it's risky to release information about a security vulnerability without having a patch in place first. Look at Blaster - I believe that the author *used a security bulletin* to write the worm and then just targeted unpatched machines.

    I think we're gonna see a lot more of this. If you release information before you fix it these days you're just inviting people to test your shiny new vulnerability ;-)

    --
    we see things not as as they are, but as we are.
    -- anais nin
    1. Re:Looks like this is the way it's gonna be... by burtman007 · · Score: 4, Interesting

      This poses an interesting dilema then: Is it better to release information on a discovered vulnerability if you know about it, or should you not release it and hope you can patch it before anyone else discovers it?

    2. Re:Looks like this is the way it's gonna be... by WwWonka · · Score: 5, Insightful

      I think the scary thing is the average shrinking time period between published vulnerability and working published exploit/worm.

      In the past it was well over thirty days, but recently that has dramatically decreased to less than that. With Microsoft's new policy of new patches every thirty days (if there is a need for them) it more than widens that window of oppurtunity for mass system compromising prior to a patch.

    3. Re:Looks like this is the way it's gonna be... by adrianbaugh · · Score: 4, Insightful

      You could always release it to the company whose product is affected and give them $suitable_time to fix the vulnerability before you post on Bugtraq. That way it isn't just you that's working on a fix, and you look like you've tried to be a responsible netizen when, having failed to fix the problem in $reasonable_time, their shit gets cracked to pieces. That has always been the responsible way of announcing vulnerabilities; I don't see that this changes the situation.

      --
      "'I pass the test,' she said. 'I will diminish, and go into the West, and remain Galadriel.'"
      - JRR Tolkien.
    4. Re:Looks like this is the way it's gonna be... by Anonymous Coward · · Score: 5, Insightful

      Yes, "script kiddies" and amateur hackers will definitely continue exploiting already-widely-known vulnerabilities, and automated worm tools will make it easier for them to do it quickly.

      However, moderately talented hackers will still be able to find and exploit vulnerabilities before they are widely known (i.e. when they are known only to a handful of hackers and possibly the software vendor, but no public disclosure has been made). This latter group makes fewer headlines but is far more dangerous.

      Already, the industry is making noises that details about the nature of the exploit should not be made available--that the vendor should just release a patch and announce to their customers "Install this. We can't tell you why." As a customer, you don't know what component you're touching, you don't know what's changing, and you don't know how to test to see if the bug was actually fixed. Blindly installing unlabelled patches is the end result of this "disclosure creates exploits" discussion.

      Disclosure does not create exploits, however. Disclosure increases the ability of amateurs to add their exploits to the pile of existing exploits. Pros, generally speaking, don't write worms that hit the whole internet. Pros break into single systems and steal data. They don't make the news, but the damage they do is much worse.

      Don't buy the Microsoft-Symantec party line. Full disclosure helps more people than it hurts. The day you become vulnerable is the day you start using software with bugs, not they day the vendor is finally convinced to make a vulnerability announcement.

    5. Re:Looks like this is the way it's gonna be... by dubdays · · Score: 4, Insightful

      That is an interesting question. I guess it would depend on where the vulnerability resides. For example, if the TCP problem could be fixed at routers of the internet backbone, then would it be beneficial for the public to have specific knowledge of the vulnerability? No, because it would lead to attacks before all equipment/software could be fixed.

      However, I can see how it would definitely be beneficial to release data to he public in other circumstances. Think about any/all OS specific threats. If those aren't released to the public, no one would even have the opportunity to fix them.

      Ultimately, I would say that vulnerabilities that lie within the realm of the end user should be made public. Those threats that would undermine the entire internet infrastructure are probably best left in the hands of those who can be trusted (as much as possible) with the knowledge, because publicly documented threats do not only go into the hands of those who are benevolent.

    6. Re:Looks like this is the way it's gonna be... by Slime-dogg · · Score: 4, Interesting

      I am for that. If the information is not released after a reasonable amount of time, the company may never take responsibility for it being there. We've witnessed this several times from a certain big company. Also, the moment that the vulnerability goes public, there should be a side note that says "The company was repeated informed of this vulnerability over a span of X months , but chose not to improve the quality of their product."

      If massive numbers of users are infected by a virus created as a result of this announcement, then the company should be held completely responsible. They would have had months to address the issue, but chose not to.

      --
      You need to restart your computer. Hold down the Power button for several seconds or press the Restart button.
    7. Re:Looks like this is the way it's gonna be... by innocent_white_lamb · · Score: 4, Insightful

      You could always release it to the company whose product is affected and give them $suitable_time to fix the vulnerability before you post on Bugtraq.

      The obvious problem with that approach is that the fact that there is no guarantee that you, as the discoverer of the vulnerability, are the first or even the fiftieth person to discover it.

      Therefore, while you're being a nice guy and letting Company X have the time to repair their software, the other 49 (or 4900) black hats are exploiting the hell out of other peoples' networks.

      Tell me there is a bug and no fix available yet, I can take my systems offline or disable something or at least consider some protective action of some kind. Don't tell me there's a bug and I'm a sitting duck until someone bothers to make mention.

      The first option seems better to me.

      --
      If you're a zombie and you know it, bite your friend!
    8. Re:Looks like this is the way it's gonna be... by theLOUDroom · · Score: 4, Insightful

      You could always release it to the company whose product is affected and give them $suitable_time to fix the vulnerability before you post on Bugtraq. That way it isn't just you that's working on a fix, and you look like you've tried to be a responsible netizen when, having failed to fix the problem in $reasonable_time, their shit gets cracked to pieces. That has always been the responsible way of announcing vulnerabilities; I don't see that this changes the situation.

      Well, let me give you a hypothetical situation where this is NOT the reasonable solution:
      You discover an OS vulnerability, not by chance, but because someone exploited it to steal your online banking information. With a little reseach, you find out that the work is being done by some zombie net with thousands of nodes that will take forever to shut down.
      The OS vendor has a piss-poor security record and you KNOW that they will take forever to release a patch, but you've found a temporary fix that while removing certain functionality, prevents the exploit.
      Should you:
      A) A post full-disclosure immediately, allowing users to quick-fix their systems and preventing countless acts of information theft.
      B) Send an email to the vendor and wait when they tell you it's going to take 6 weeks to fix.

      The problem with your approach is that it assumes no one but the vendor can do anything about the problem. The user always has the choice to quit using the affected product.

      --
      Life is too short to proofread.
    9. Re:Looks like this is the way it's gonna be... by theLOUDroom · · Score: 3, Insightful

      Yea, the same users who don't install well known years old patches are going to search out and early adopt a patch from 'some guy'. Puhleeze.

      Those are the users who are going to ge hosed no matter what. It doesn't matter if you choose A or B they're still going to get owned.
      Since you can't do anything about them, you should be worried about they people who are actually going to do something once they hear the announcement.

      --
      Life is too short to proofread.
    10. Re:Looks like this is the way it's gonna be... by Anonymous Coward · · Score: 3, Insightful

      There's a fundamental difference between your scenario and the traditional vulnerability discovery: the existance of an attack in the wild. In your case, you are not so much writing up the discovery a vulnerability as you are writing up a report on an attack that just in your scenario exploits a previously unknown vulnerability.

      Why is this important? Most people have this dualistic view of the world that tends to come down to the concept of inevitability. See, in your scenario, the attack is already out there, that is, it is inevitable there will be an attack because an attack already exists. Releasing an immediate writeup of workarounds is considered a good thing because you will be protecting people from an attack in the wild. Of course, informing the vendor and the antivirus/personal firewall crowds at the same time would be a good thing. Not only will this increase the likelyhood of your workarounds being implemented while the vendor works on the patch (by being recommended on "reputable" sites), but it could provide increased protection against the attack if the AV vendors could incorporate signatures into their products.

      Now compare this to a vulnerability report about a new vulnerability without any attacks in the wild. In this case, most people don't see the attacks as inevitable. In fact, thanks to certain minor propoganda that occurs these days, they see the report as precipitating the attack. Thus if you release the report without reasonable effort to contact the vendor for a patch, they see you as the "evil" one for "telling" the malware writers a new way into their system. In their minds, if you hadn't of released the report then the inevitability would be that there would be no attack (let's not get into how this isn't technically correct, we're talking about Joe Public here, not security experts). That's why most vulnerability discovers should work with the vendor on patches or mitigations before releasing the report. Otherwise people will really start to make the false assumption that it's the vulnerability discovery that's the problem, instead of the vendor's flaws.

  3. The Internet's broken? by Anonymous Coward · · Score: 5, Funny

    When will I be able to download a fixed version?

    1. Re:The Internet's broken? by lukewarmfusion · · Score: 4, Funny

      I'll have a copy on your desk by morning.

      I once had a woman ask me if I could speed the Internet up for her presentation. I told her I'd open the valve up a little bit, just for her. *big smile* I love helping customers.

  4. Secret repairs! by Anonymous Coward · · Score: 5, Funny

    The best kind!

    "What are you doing?"

    "Can't tell you."

    "When will you be done?"

    "Can't say."

    "Is there anything you can tell me?"

    "This will save your life."

    "Really?"

    "No."

  5. It's the users' fault! by heironymouscoward · · Score: 4, Funny

    Any user without the technical competence to inspect and repair TCP/IP packets on the fly should not be allowed to use the Internet. Such vulnerabilities only exist because people too lazy and ignorant to download the patches for their Cisco routers!

    --
    Ceci n'est pas une signature
  6. Paradox by Prince+Vegeta+SSJ4 · · Score: 5, Funny
    The TCP issue publicized yesterday was publicly known as early as 1998

    Yesterday was 1998? Whew, I thought it was 2004 and 6 years of my life were wasted

  7. Hooray for editing! by consolidatedbord · · Score: 3, Funny

    "We ran a story on a this a few days ago." What's a "this" ?

    --
    while true ; do echo this is my sig; done
    1. Re:Hooray for editing! by s20451 · · Score: 4, Funny

      It's a pointer to self. Useful for creating dupe stories:

      story_type dupe = this->return_story();

      --
      Toronto-area transit rider? Rate your ride.
  8. Re:"super" exploits by The+Angry+Mick · · Score: 4, Funny

    What is a "super" exploit???

    It's the one with the red "S" on its chest . . .

    Ba dum bump.

    --

    I'm not tense. I'm just terribly, terribly, alert.

  9. Re:IPv6 by leerpm · · Score: 4, Informative

    No. TCP is a different layer than IPv6. It has no effect on IPv6 or IPv4.

  10. Net threat overstated, says Paul Watson by Bimo_Dude · · Score: 5, Informative
    according to this article on C|net.

    From the article:
    "The actual threat to the Internet is really small right now," Watson said on Wednesday. "You could have isolated attacks against small networks, but they would most likely be able to recover quickly."

    --
    "Teleporting Rodents with D-Cell Battery Displacement" theory -- IgnoramusMaximus (692000)
  11. Security through Obscurity proves itself again by Anonymous Coward · · Score: 3, Interesting

    It's effective when used as the external skin of a layered approach.

    Some would say it should be disposed of entirely, in favor of the bugtraq, etc. totally-open approach.

    That approach is IMO foolish. Why throw away a useful layer of security? In 1992 it was debatable; the interim years have shown without a doubt that the totally-open approach produces more script kiddies than it does patched systems.

    1. Re:Security through Obscurity proves itself again by aug24 · · Score: 5, Informative

      Rot. Non-full-disclosure has generally meant that we didn't have any progress at all cos the vendors typically wouldn't do jack till they had to.

      For instance, there was a mail on BugTraq not too long ago about a bug that the finder chased with whichever company it was for about six weeks. No reply. No acknowledgement, no fix. He gave up and went open - they fixed it in a week.

      Now, how many other people had found that bug and were trying to make an exploit out of it? What if he had kepy schtum and the black-hats had got in?

      That's what full-disclosure is for, to force vendors to fix stuff they could otherwise ignore.

      Justin.

      --
      You're only jealous cos the little penguins are talking to me.
  12. I'm of 2 minds on this by platypibri · · Score: 4, Insightful

    Yes, I would prefer to know immediately if I was vulnerable. However, the vast majority of defense is against script kiddies who wait to have exploits handed to them so they can copy and paste some malicious code together to prove what "hackers" they are. Why should we tell them before there's a patch? I dunno. Hopefully someone smarter than me is working on it.

    --
    Yeah, I guess I'm funny like that.
  13. this is not uncommon by quelrods · · Score: 5, Informative

    Usually people take it upon themselves to notify vendors of bugs and give them time to work on patches or workarounds before releasing the information. For anyone that reads full disclosure lists such as bugtraq this is very commoon. Also, when the bug affects key internet infrastructure, the admins of big isps/colos/routers are informed and given time to patch. This is good for the internet and good for vulnerability researches instead of looking like malicious people who just want to destroy the internet.

    --
    :(){ :|:&};:
  14. Re:IPv6 by Anonymous Coward · · Score: 5, Informative

    IPv6 is a layer below, thats why its called TCP/IP. IPv6 is only an addressing scheme for bit packing, and how many bits in a reference. Tcp is above it, they are independent of each other. For more information google "OSI Network Layer Model".

  15. Fixing the internet... by Eagle5596 · · Score: 4, Funny

    Dilbert is in the Boss's office.

    Dilbert: I discovered a hole in our internet security.

    Boss: What?!!

    Boss: Good grief, man! How could you put a hole in our internet?

    Dilbert, angry: I didn't PUT it there, I FOUND it.. and it's not...

    Boss: It's your job to fix that hole. I want you to work 24-7!

    Dilbert: Actually, that's NOT my job. But I'll inform our network management group.

    Boss, yelling: PASSING THE BUCK!!! YOU'RE A BUCK PASSER!!!

    Dilbert: Forget it! There's no hole! It got better!

    Boss: That's more like it.

    Last panel, the boss is sitting alone smiling.

    Boss thinks: I fixed the internet.

  16. Paranoia? by dawg+ball · · Score: 3, Interesting

    Is this just a case of paranoia reigning supreme? From what I understand of this problem (And it is very possible that I don't know all the details) it only poses a risk under a very specific set of circumstances and that this set of circumstances is very common. Are we becoming ParaNET?

  17. RedHat or Linux Kernel Fix? by osewa77 · · Score: 3, Informative

    Many networks used home-grown routers based on Linux, FreeBSC, user-space TCP/Firewall/VPN implementations, or even windows. However, the vendor list only includes commercial router manufacturers. This seems to me like a serious problem waiting to happen; the would-be exploiter now know what systems would remain unpatched for a long time.

    1. Re:RedHat or Linux Kernel Fix? by stratjakt · · Score: 5, Informative

      The problem affects mainly huge peering sessions between big routers, the kind that last for days. You can essentially trick the routers into dropping the peering sessions, leading to route flapping and other hassles.

      Big backbone providers don't generally use home-grown linux routers.

      It has no real bearing on some home/office router running linux made out of an old 486.

      --
      I don't need no instructions to know how to rock!!!!
  18. Re:still on topic, troll by mustangsal66 · · Score: 3, Funny

    There are people who use Windows boxes as routers

    Now that's scary...

    Imagine the techsupport on that mess...
    ... Now right click, select BGP... Click peer...
    ... That's correct sir... it's probably not a good idea to run IIS on your core router...

    --
    Why worry? Each of us is wearing an unlicensed "nucular" accelerator on his back.
    Sig changed for readability by G.W.
  19. Re:"super" exploits by richard_willey · · Score: 3, Informative

    What dinkleberries modded this up to a 5???

    Let's make a few things clear:

    The attack in question is a method to reset a TCP connection. The TCP reset is launched against one of the two end nodes participating in the TCP connection. The router has NOTHING to do with this. In theory, if an intermediate system like a router goes down, IP will simply find a new path arround the outtage.

    The reason that routers feature prominently in this discussion is that Border Gateway Protocol uses very long lives TCP connections. In turn, this means that routers are very vulnerable to this attack. However, the vulnerability effects routers in their roles as an end nodes (sending or recieving data) rather than their role as an intermediate system (forwarding traffic)

  20. "Secret Repairs Preceded TCP Flaw Release" by Anonymous Coward · · Score: 4, Funny

    And now you blew it! Thanks a lot.

    Now if you'll all step this way please...

  21. Diversity by MachineShedFred · · Score: 4, Funny

    Hey! He has an Italian typing accent, you insensitive clod!

    --
    Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
  22. Re:IPv6 by tbaggy · · Score: 3, Informative

    IPv6 could be used to alleviate this by using Ipv6 network layer encryption. Still, it would be easier to just MD5 your BGP tcp sessions or fix the tcp stack with a patch vs. move to IPv6

  23. Why is everyone freaking now? by fremen · · Score: 4, Informative

    This attack vector has been known for years, and the TCP windowing nonsense has too. Programs like tcpkill have used the RST trick in conjunction with TCP INS windows for a while and have seen quite a bit of use. What's new with this attack that wasn't already in the wild?

    1. Re:Why is everyone freaking now? by Anonymous Coward · · Score: 3, Informative

      What's new is that someone found an efficient
      way to exploit it. Before, it was inefficient
      to exploit it.

  24. Re:secret? by divisionbyzero · · Score: 4, Informative

    What a troll. Yes, because everyone who doesn't setup MD5 is obviously lazy or stupid, unlike you and your smart friends. Please. There is obviously overhead with doing MD5 and it is reasonable not to use it for performance reasons. Anyway, as someone already mentioned, the vulnerability is in TCP which means the MD5 solution works for BGP, which is the most vulnerable, but does nothing for anything else built on TCP (e.g. DNS).

  25. OpenBSD is not vulnerable by chrysalis · · Score: 4, Informative

    No, everyone is not vulnerable to the recently published vulnerability in the TCP protocol that allows to shut down BGP routers. Because Cisco hardware is, stupid writers yell that the whole internet is vulnerable. Come on, Cisco is not the internet.

    As stated by Theo de Raadt and Henning Brauer, OpenBSD is not vulnerable because (quoting Henning) :

    Even without TCP MD5, bgpd on OpenBSD is not affected, because:

    we use random emphereal ports
    we do not use insanely hughe window sizes as Cisco does
    we require the RST sequence number to be right on the edge of the window

    (quoting Theo) :

    That is right. If you have a Cisco, you can tear down BGP sessions by spoofing:

    64K of

    SYN?s or RST?s sent to #.#.#.#:179 -> #.#.#.#:{1024,+512,+512,...}

    The SYN and RST methods are different, but the end effect is that a tiny little burst of packets will cause a flap.

    OpenBSD (and I am sure other systems too) have for some time contained partial countermeasures against these things.

    OpenBSD has one other thing. The target port numbers have been random for quite some time. Instead of the Unix/Windows way of 1024,1025,1026,... adding 1 to the port number each time a new local socket is established? we have been doing random for quite some time. That means a random selection between 1024 and 49151. This makes both these attacks 48,000 times harder; unless you already know the remote port number in question, you must now send 48,000 more packets to effect a change.

    We?ve made a few post-3.5 changes of our own, since we are uncomfortable with the ACK-storm potention of the solutions being proposed by the UK and Cisco people; in-the window SYN or RST?s cause ACK replies which are rate limited.

    It will have the most impact on vendors who do BGP over poor TCP stacks. In particular, Cisco.

    Cisco has not been teaching engineers to block SYN?s coming in; they have only been teaching them to block SYN-ACK?s from going out in return. And? well, you?ll see.

    Ehm, actually OpenBSD is vulnerable. To quote Mike Frantzen : The exploit has a one in 206,703,891,006,465 chance of succeeding. An exhaustive search would require 11,162,010,114,349,110 bytes of traffic which would take 962 days at a saturated gigabit per second. Or two hundred years on a T1. :)

    --
    {{.sig}}
  26. Smithsonian's Storage by Gunfighter · · Score: 3, Interesting

    Funny you should mention that scene. I've been to the Smithsonian's storage facilities in Silver Hill, MD on numerous occasions. The final scene of the Ark rolling down an aisle with unknown treasures stacked floor to ceiling on either side isn't too far from the truth. The individual football field-sized containers are called "pods". They're highly guarded and environmentally controlled.

    My favorite resident of the pods was the stuffed black rhino that the Smithsonian didn't want to put on display because the animal is extinct and they didn't want any controversy over it.

    The scary thing is that if you took the time to look at every individual item on display in the Smithsonian for a few seconds, it would take you several years. If they actually had their entire collection displayed (they have crap tucked everywhere, not just in the Silver Hill storage facility), it would probably take you several lifetimes. There's no telling what they have stashed away.

    The Smithsonian's "Secret Repairs" are handled by the Smithsonian Center for Materials Research and Evaluation (http://www.si.edu/scmre/index.asp). SCMRE is, conveniently enough, primarily located at the Silver Hill storage facility.

    --
    -- Stu

    /. ID under 2,000. I feel old now.
  27. MD5 isnt enough by Alan+Cox · · Score: 3, Interesting

    The MD5 auth hack unfortunately fixes only some of the issues here. There is a second way to disrupt streams involving shrinking the MTU to a stupid level, and the "aim for the window" tricks observed in the other attack apply here too.

    Going back to 199x it was known that you could hit long lasting streams with ICMP must-fragment mtu = 80 and similar values and basically stall the stream. Some stacks correctly turn off MTU discovery faced with such a claim others ignore it (and break on low mtu links), and others believe it (and break spectacularly). The routters in the middle of the stream have no knowledge of the MD5 or other secrets so can only reply in untrusted form. It is possible to do some checking from the reply data but not full checks.

    To make it more fun the proposed fix seems to open a new exploit path that may be worse. Fortunately there is a trivial fix for this case if the problem is confirmed real.

    The ultimate problem though is ISPs not filtering packet source addresses. If the governments want to pass one sane bit of 'cybersecurity' law then filtering end users to stop source address spoofing would be it, and require they only used their legitimate assigned addresses (or other addresses properly owned by one way downlinks like satellite etc)

    Alan