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.
This was reported three days ago by another reader.
Yawn.
bash: rtfm: command not found
No. TCP is a different layer than IPv6. It has no effect on IPv6 or IPv4.
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)
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.
:(){
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
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".
I don't really know what to make of what your saying, okay sentence one must be a joke right? Sentence two, are you aware _many_ network technicians have to look after upwards of 100 routers?
(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?)
Mod +5 Drunk
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.
IPv6 is more than a drop in replacement for IPv4 at Layer 3 of the OSI model. Everyone just assumes that since things map best to a model, that it is 100% accurate. TCP/IP is represented best by it's own model, the DoD Model. In this model IP falls into layer 2... TCP and UDP is layer 3. This really doesn't make much of a difference though. In a layered communication model, each layer has to be aware of the layers directly above and below in order to properly pass the information on. Ethernet has to know if it needs to give information to the IP stack, or perhaps you are using IPX instead. IP is not completely "layer 3," and it cannot do its job alone. IP has many helper protocols that straddle various layers. One example is ARP, it gives it the ability to determine which MAC address it should forward a packet to. If it didn't know, then layer 2 couldn't address it properly (it could broadcast, but do not look too far into this).
The point is, IPv6 does not just replace the IP "proper," but many of the helper protocols as well. The interaction it has with layer TCP and UDP could be slightly different, but I have not looked into this...
Another food for thought... why do you have to have IPv6 enabled Application layer services? Because things are not so cut-and-dry as the layered model theory suggest, in practice.
Politics, Life, and More on my Aspiring for the Future
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.
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)
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
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?
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).
Almost all worms based on Microsoft OS vulnerabilities were released MONTHS after the patch was made public.
IPv6 is immune, and in a grand display of irony, IPX/SPX is also safe.
"God is a comedian playing to an audience too afraid to laugh." -Voltaire
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}}
I have no idea about BGP, or the decisions made, but I can speak from the credit card standpoint. It used to be that credit card transactions (not a-sync, TCP only.), would connect, send transaction, wait 10-30 seconds, then disconnect. This has changed over the past 5 years or so for many vendors, who have now switched to an "always up" state. The reason before was bandwidth was an expensive commodity, but with the prices now, it's better to have a connection stay always online so that as soon as there is a connection issue it can be detected by the host server, the thinking there is you can correct many incidents before the customer/store is even aware there is an issue. Security is not a concern for either of the formats as the link must be encrypted, and private.
Mod +5 Drunk