Secret Repairs Preceded TCP Flaw Release 204
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.
Cisco Fix (Score:5, Informative)
Re:Cisco Fix (Score:5, Interesting)
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 [merit.edu] about looking glasses being too free with info that would allow a TCP reset in one try.
Re:Cisco Fix (Score:2)
Yup. [slashdot.org]
-dk
Looks like this is the way it's gonna be... (Score:5, Insightful)
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 ;-)
Re:Looks like this is the way it's gonna be... (Score:4, Interesting)
Re:Looks like this is the way it's gonna be... (Score:5, Insightful)
Re:Looks like this is the way it's gonna be... (Score:5, 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.
Re:Looks like this is the way it's gonna be... (Score:2, Informative)
Re:Looks like this is the way it's gonna be... (Score:4, Insightful)
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.
Re:Looks like this is the way it's gonna be... (Score:5, Insightful)
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.
Re:Looks like this is the way it's gonna be... (Score:3, Insightful)
Re:Looks like this is the way it's gonna be... (Score:3, Insightful)
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.
Re:Looks like this is the way it's gonna be... (Score:3, Insightful)
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 th
Re:Looks like this is the way it's gonna be... (Score:5, 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.
Re:Looks like this is the way it's gonna be... (Score:3, Insightful)
At the place I work, if we find a severe bug, we personally call every company that has that version of the software and have them download an update. My company doesn't produce networking software though and we only have 50-75 companies running any given version of our product at one time. This is usually bugs that affect mathematical calculations though or cause database corruptions.
From the point of view of a customer: if I found a serious fla
Re:Looks like this is the way it's gonna be... (Score:3, Insightful)
Publicly releasing the info would not benefit me in any way unless I was a security products vendor hoping to cash in on Cisco's failure.
I mostly agree.
If the vendor refuses, within a reasonable time frame, to fix the problem taking it public may be the only way to force them to do so.
You might also consider that while you may have a means of protection (vendor supplied or home grown) others are still vunerable. And this may impact you. And thus it may be to your benefit to alert others.
SteveM
Re:Looks like this is the way it's gonna be... (Score:5, Insightful)
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.
Re:Looks like this is the way it's gonna be... (Score:2)
Re:Looks like this is the way it's gonna be... (Score:2)
Re:Looks like this is the way it's gonna be... (Score:5, Insightful)
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.
Re:Looks like this is the way it's gonna be... (Score:2)
I wonder if this is a variation of the argument regarding whether we should "Slow Down the Security Patch Cycle? [slashdot.org]"
The story you tell about Blaster is similar to the Computer World story regarding the Witty worm [computerworld.com]:
Re:Looks like this is the way it's gonna be... (Score:2)
It's not only risky, it's possibly actionable in a court of law (to be tested) if someone discovers a vulnerability and negligently releases it causing panic and disruption. There are precedents in copyright and confidential information that reduce or penalise the defence of "in the public interest" where the disclosure was not responsible. For example, in some cases it is better to go to the police first. If the police don't resolve the problem in adequate time, then it's justified to take it a more public
Re:Looks like this is the way it's gonna be... (Score:2)
The Internet's broken? (Score:5, Funny)
Re:The Internet's broken? (Score:5, Funny)
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.
Re:The Internet's broken? (Score:2)
Re:The Internet's broken? (Score:2)
Secret repairs! (Score:5, Funny)
"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."
Re:Secret repairs! (Score:3, Funny)
Smithsonian's Storage (Score:4, Interesting)
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.
It's the users' fault! (Score:5, Funny)
Re:It's the users' fault! (Score:3, Informative)
(It would be physically impossible to do what your saying, you can't inspect and repair a "Tcp/ip" packet? Block it maybe, although blocking ACK packets would fundamentally break TCP.IP? Even if you could don't'cha think you'd timeout the socket before you could re-transmit?)
Re:It's the users' fault! (Score:2)
Yes, you COULD "inspect and repair" packets on the fly by becoming the TCP/IP stack yourself and mangling them appropriately before acting on them.
I can only imagine what that would do to network speeds, however...
Re:It's the users' fault! (Score:2)
Re:It's the users' fault! (Score:2)
Yea, but after a while you'd get so backed up that by the time you got done handling each packet, you'd have to decrement the entire remaining TTL and drop it. God help you if you've configured yourself to also send back an ICMP packet to let the other end know what happened.
Re:It's the users' fault! (Score:2)
Re:It's the users' fault! (Score:2)
In any case, whether you have 1 or 1000 routers, it is your responsibility to make them interact correctly with public networks.
Re:It's the users' fault! (Score:2)
Paradox (Score:5, Funny)
Yesterday was 1998? Whew, I thought it was 2004 and 6 years of my life were wasted
Re:Paradox (Score:2, Funny)
Old News (Score:3, Informative)
Yawn.
Hooray for editing! (Score:3, Funny)
Re:Hooray for editing! (Score:5, Funny)
story_type dupe = this->return_story();
Re:Hooray for editing! (Score:2, Funny)
"We ran a story on a this a few days ago." What's a "this" ?
It makes more sense if you read it like Mario would.
Re:Hooray for editing! (Score:2, Funny)
Just a question (Score:2)
(yes that was on purpose)
Diversity (Score:5, Funny)
IPv6 (Score:2, Interesting)
Re:IPv6 (Score:2)
Re:IPv6 (Score:5, Informative)
Re:IPv6 (Score:5, Informative)
Re:IPv6 (Score:2, Informative)
Re:IPv6 (Score:3, Informative)
Re:IPv6 (Score:2, Informative)
Net threat overstated, says Paul Watson (Score:5, Informative)
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."
Re:Net threat overstated, says Paul Watson (Score:3, Insightful)
There have been cases of "fossil" IP blocks being hijacked in the last few years by spammers. (Sometimes as simple as registering an expired domain that an ancient contact email address points to.) They seem to be paying for malware to be written. Don't
Security through Obscurity proves itself again (Score:3, Interesting)
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.
Isn't BGP an open protocol (Score:3, Interesting)
However I cant see why BGP needs to implement a large window - in fact in a device which needs to run as fast as possible it's surely disadvantageous.
I've seen TCP RST attacks in the mid nineties actually used on IRC - only the application of the exploit to bgp is n
Re:Isn't BGP an open protocol (Score:2)
you do realize that the window on OSes like BSD and Linux isn't anywhere near as big as it is on some of these routers. This has nothing to do with the bandwidth.
This exploit takes advantage of the fact that the router vendors have very predictable TCP implementations.
Re:Security through Obscurity proves itself again (Score:2, Insightful)
I think the whole reason the "totally open" approach exists, and will always exist, is to deal with unresponsive vendors. If a software vendor (who shall remain nameless) sits on a major security bug for six months, there is a problem with the "security through obscurity" model, and it's this--there is no profit motive to fix security bugs nobody knows about. If customers think they're safe, that'
Re:Security through Obscurity proves itself again (Score:5, Informative)
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.
Re:Security through Obscurity proves itself again (Score:2)
Security through obscurity works... (Score:2)
2. If the company actually is responsive and bothers to fix it. Given time, black hats will find it and have a new and unknown exploits. If they in addition cover their tracks well, it could do considerable damage before found and fixed. So
Re:Security through Obscurity proves itself again (Score:2)
Open/Obscuring The Wrong Things? (Score:2)
However in actual code and software systems, security through obscurity is weak and fallacious. Just because the general user base doesn't know a system is exploitable means the system is still secured. The exploit there whether or not the users realize it. Op
I'm of 2 minds on this (Score:4, Insightful)
Re:I'm of 2 minds on this (Score:2, Interesting)
Re:I'm of 2 minds on this (Score:3, Insightful)
this is not uncommon (Score:5, Informative)
Re:this is not uncommon (Score:2)
One must wonder why such companies don't assume that there may be dozens of other people that have independently discovered the exploit and are USING it rather than reporting it.
Fixing the internet... (Score:5, Funny)
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.
Paranoia? (Score:3, Interesting)
/Becoming/ Paranoid? (Score:2)
In fact, these days I believe Bill Hicks was killed by the Beiderbeck Group using carcinogenic material supplied by the CIA under the orders of undead vampire George Bush Snr!
Justin.
RedHat or Linux Kernel Fix? (Score:4, Informative)
Re:RedHat or Linux Kernel Fix? (Score:5, Informative)
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.
"Secret Repairs Preceded TCP Flaw Release" (Score:4, Funny)
Now if you'll all step this way please...
Why is everyone freaking now? (Score:5, Informative)
Re:Why is everyone freaking now? (Score:3, Informative)
way to exploit it. Before, it was inefficient
to exploit it.
trap? (Score:3, Interesting)
That would make a lot more sense. Protect against the exploit, publicize it, then watch what happens to determine which groups are most adept at quickly exploiting published vulnerabilities and raid their location. Neat idea for a large-scale honeypot.
Although, most of us know that the majority of exploits are now being deployed by spammers. They don't have any incentive to take major backbones down so this effort might just reveal a few more script kiddies that aren't really the problem.
Re:trap? (Score:2)
The exploit depends on a spoofed source IP address. There's no way of tracing it back to the true source.
Re:trap? (Score:2)
OpenBSD is not vulnerable (Score:5, Informative)
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.
Re:OpenBSD is not vulnerable (Score:2)
Well, no, and technically, the transformer substations aren't the power grid, and the switches aren't the phone network. But whether you're susceptible or not, it's not going to matter if your upstreams' routes dampen because they (like just about everyone) are using susceptible Cisco or Juniper routers.
Re:"super" exploits (Score:5, Funny)
It's the one with the red "S" on its chest . . .
Ba dum bump.
Re:"super" exploits (Score:2, Funny)
(-:
Re:"super" exploits (Score:2, Informative)
Re:"super" exploits (Score:4, Informative)
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)
Re:"super" exploits (Score:2)
Re:"super" exploits (Score:3, Insightful)
This isn't a TCP problem, it's just being billed that way because a bunch of vendors have crappy implementations of the above protocals. Yes, in theory this could affect everyone, but the difficulty of doing this type of attack on a system with a good TCP implementation is next to nothing.
Basically, the attack takes advantage of certain predictable behaviors that arn't in the spec but that most of the T
Why is BGP maintaining persistent connections (Score:2)
... Which brings up something I was wondering about when the /. article was posted the other day: Why is BPG a persistent connection? From an architectural perspective? That seems like a weak design decision, to me, but perhaps I just don't know enough about BGP....
Also, it was my understanding the credit card transaction processing was "aperiodic", intentionally not hold
Re:Why is BGP maintaining persistent connections (Score:3, Informative)
Re:Why is BGP maintaining persistent connections (Score:2)
Re:Why is BGP maintaining persistent connections (Score:2)
An answer you don't want... (Score:2)
Now, as then, I think it's just best not to ask
Re:Nice work! (Score:2)
Re:still on topic, troll (Score:3, Funny)
Now that's scary...
Imagine the techsupport on that mess...
RTFA (Score:2)
It addresses this. I promise you.
Re:secret? (Score:4, Informative)
MD5 isnt enough (Score:4, Interesting)
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
Re:MD5 doesn't solve the problem (Score:2)
Ah! So it's a windows problem. I knew it! I knew it! I knew it! It's always their fault!