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.
"super" exploits
What is a "super" exploit??? Not jsut an exploit but a "super" one. Are there any of these "super" exploits on any non-windows systems?
Evolution or ID?
Does anyone know if this affects IPv6? I wonder if this situation could somehow be leveraged to promote it...
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?
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.
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?
The Erogenous Zone
What we need is a not-for-profit organization with a team of researchers finding secuirty holes in common software, with a pay-to-subscribe list where the security holes can be released to those that need the information before the script kiddies. Script kiddies probably wouldn't pay to get on this list and thus get the proof of concepts. There are other issues as well though... like what happens when some script kiddy does pay to get on and then leaks all the informaiton to other script kiddies. Or when some company sues the not-for-profit for pointing out a hole in thier software.
I don't think there can be any solution and we just have to conitinue on how we have been - patch ASAP when new patches come out (with proper testing of course) and hope you don't get exploited in the time that takes, and if you do get hacked take the box offline and rebuild (or replace with a backup if you have one available).
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.
The whole TCP window thing seems entirely obvious to me, i just hadn't realised that windows were sufficiently big to be guessed. As we start to see faster and faster transfers we'll need larger and larger windows and this will just get easier.
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 new.
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.
I'm wondering why all the hooplah about this, especially after steps were taken to deal with it before publicizing it... unless at the same time, systems were put in place to ID attempts to exploit the vulnerability.
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.
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.
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