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.
is here as posted from an article on the register.
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
When will I be able to download a fixed version?
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."
TCP Vuln is a well known attack, way before '98.
MD5 authenticated BGP Sessions have been around for ages, it's just *lazyness* of peering vendors to implement it.
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
Yesterday was 1998? Whew, I thought it was 2004 and 6 years of my life were wasted
This was reported three days ago by another reader.
Yawn.
bash: rtfm: command not found
"We ran a story on a this a few days ago." What's a "this" ?
while true ; do echo this is my sig; done
Does anyone know if this affects IPv6? I wonder if this situation could somehow be leveraged to promote it...
It's the one with the red "S" on its chest . . .
Ba dum bump.
I'm not tense. I'm just terribly, terribly, alert.
no Linux is still working on the implementation of TCP... its not well documented enough so they have to reverse engineer it
(-:
Get paid to code OSS
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)
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.
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.
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.
:(){
RTFA, he copy & pasted the first paragraph from the article for the summary. Go blame "richm" at netcraft for that.
It's an exploit that could affect the core routers of the internet. This one could technical reset 100% of webtraffic going through a particular router, in theory. Of course, this won't make a lick of difference to your average webserver, as they handle many connection resets a day. It would only affect those sites that traffic is so large that if all connections were reset it would cause a flood of re-connects thereby socking bandwidth. This is more directed at always up type connections, such as Telnet, SSH (as the article points out), credit card traffic, etc.. HTTP is constantly dropping and connecting anyways..
Mod +5 Drunk
Trolls like to play the martyr--"You're trying to cover up what I'm saying because it's true; reply to my posts instead of modding me down." Well here's your reply, bitch. When Micro$oft's crappy software allows vulnerable machines to act as spam relays, or spread worms around the internet, everyone suffers. No matter what OS they use.
Si la vida me da palo, yo la voy a soportar Si la vida me da palo, yo la voy a espabilar
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.
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
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.
maybe you should read the article.
:)
It addresses this. I promise you.
Photos.
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 don't know that it could really reset 100% of traffic going through a router. As the article states, most TCP connections don't last long enough for such an attack to be executed. BGP, one of the core routing protocols however, relies on relatively long TCP connections, and hence the exploit could seriously screw up internet routing.
"The problem with internet quotations is that many are not genuine" -Abraham Lincoln
How come the editors don't go back and fix their typos? Taco, Michael, and company must genuinely not a care.
(yes that was on purpose)
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)
Hell man, I've been actively working on my paranoia and tin-foil-hat persona since I started writing code!
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.
You're only jealous cos the little penguins are talking to me.
And now you blew it! Thanks a lot.
Now if you'll all step this way please...
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.
... 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 holding open a connection? It was my understanding that this, too, was for security reasons. Certainly either always up or periodic operation of a connection would seem to weaken the design from a security standpoint. It was my understanding of basic security procedures (both offline and online) that unpredictible behaviour of the potential target was considered a Good Thing(tm).
"The Internet is made of cats."
As discussed on the NANOG-list (http://www.nanog.org), and admitted by Cisco, the MD5 hash is calculated BEFORE determining whether the source IP or TCP window checks are performed. Thus, instead of just resetting a session, you can wipe out a whole router just by pointing MD5 garbage at an IP address which is listening for it. A typical core router (7500/GSR/etc) can generally accept about 10mbps or so of MD5. It's not that hard to generate that much traffic w/zombies...
Need Geek Rock? Try The Franchise!
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?
Reminds me of when I asked my brother "WTF is a Super Saiyan?"
:o)
Now, as then, I think it's just best not to ask
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.
Woah, that herring of yours is glowing in the fucking dark...
Opportunity knocks. Karma hunts you down.
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}}
And if a router is routing traffic between to end points it can't be targeted to close the session? What about a NAT router..? Proxy??
Mod +5 Drunk
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
... you are trying to blackmail or extort them. they might think that, no matter how you word your missive to them.Your word against their word then if anything happens. Then it might be better that you release your information publically,as soon as you have it, but you won't know about how the former way would work out until you tried it, and you might get burned by the "shoot the messenger of bad news" philosophy. I garner from reading here and there sometimes-not always but random chance sometimes- companies just plain don't like having flaws pointed out to them. Consider the history of back orifice for instance.
Try the waitresses. And don't forget to tip the veal.
--
Cain.
On a kinda related note, I just heard about a high risk security flaw in the "Hello World" program. The hacker can take the output and use it as a ddos attack to break into your flawed system. No patches are available to date.
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 TCP implementations have to reduce the possible space of packets to something that is reasonably tryable.
The policy of the United States is worse than bad---it is insane. -- Ludwig von Mises, Economic Policy(1959)
1. If you know who to keep in the loop, and who not to. If the blackhats get it early, you're even worse off than before because then people think they have more time to fix it. Obviously OSS is rarely a good candidate, since it's trivial to join mailing lists and such.
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 unless they fix it in a timely manner, you're better off releasing it anyway to put pressure on them to fix it.
3. With the current patch rate of most machines (sigh) they may write an exploit based on the patch, rather than a security bulletin and still catch a large percentage off guard. Not that full disclosure does any better, just that either solution can't fully solve the problem of exploits made on basis of the patching process
Kjella
Live today, because you never know what tomorrow brings
And hence, the routing is screwed up and possibly 100% of the traffic through that router is dropped or routed inappropriately.
What you desribe isn't "security through obscurity" complaint many close vendors try to get away with. After all most username/password creditial security schemes depend on this: you keep your password a secret (and if you can your username too!).
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. Operating under a blanket of secrecy for algorithms and code is dangerous and bad practice.
Bugtraq is a good thing because ignoring bugs in code is akin to sticking your head in the sand. A vendor being very open with bugs in their software is a very good thing.
Keeping security network topology and interconnects a secret is a good thing. Keeping passwords a secret is a good thing.
So please never confuse these two. No one on Bugtraq is going to be interested about my passwords or how my networks are laid out. I can keep that a secret. However if I release software that deals with security that effects many users then Bugtraq has every initiative expose problems.
As for this specific problem, I'm glad people where open about this. Now that people know that long term connections are vulnerable they can take action to either start working on fixes or work arounds. Hiding the problem wouldn't have helped one bit.
OK, this vulnerability is not new. It's been around for years, in fact. I recall exploits being used as early as 1996-1997. I'd have to do some heavy digging to find them, and I don't even think I have a hard drive or tape that old around anymore, so no clue if I've got one backed up somewhere..
How am I supposed to fit a pithy, relevant quote into 120 characters?
The clandestine repair effort livened an already intense period for security pros already juggling a bevy of Windows security patches.
So basically if the Internet falls apart we can still blame Microsoft.
Oh good.