Slashdot Mirror
TCP Vulnerability Published
Bob Slidell writes "According to Yahoo!, there is a critical flaw in TCP that affects everyone and everything. The article is scant on details and long on fear, hopefully someone will post more details on this." The advisory has more information, and is long on details but only moderate on fear.
This just hit the misc@openbsd mail list:It sounds (again) like proactive security auditting saves the day!
This kind man responsible for finding this vulnerability is going to present this exploit at the security conference in Vancouver this Thursday. He then predicts "hackers will understand how to begin launching attacks 'within five minutes of walking out of that meeting.'" The article talks about how the government has been "fortifying" its networks against this, does that means they quickly rewrote the tcp protocol? I would love to know.
I'm removing support for TCP right now. Give me UDP or give me death!
Looks like someone left ISEXPLOITABLEFLAG = TRUE in the code.
The Blaster Master Fighting for Truth, Justice, and Evil Pie since 1979
Move along, little to see here.
John.
As a web designer, taking advantage of this could get me off work faster than a snow storm. I don't know if I'm afraid or enthused. ;)
to switch over to IPX
Your computer is broadcasting an IP address!
Seriously though, it doesn't look all that bad. (Nor does it look all that hard to do, but still..)
www.gotontheinter.net
Updated vaguely once a whenever, maybe once a whenever-and-a-half.
Just unplug your PC from the internet
How would that keep you safe from DoS attacks?
Do you care about the security of your wireless mouse?
I'm no expert, but wouldn't a security problem with TCP be completely unrelated to IP?
more like:
UDP just I. switch ll'll to I just
S
I don't think so.
Looks like the weakest point for net-wide effects in routers implementing BGP. A concerted attack could tie up critical routers rebuilding routes after losing connection to their peers. Since this could be globally critical, I suspect the major hardware vendors and service providers will be jumping through hoops to get the fix in before some blackhats get coordinated with an exploit. There would still be weaknesses, but IPv6 will get to sit idle a bit longer.
As frightening as this "vulnerability" sounds, this is nothing really new; other TCP weaknesses are syn floods (not quite the same thing, but somewhat similar -- in fact, this vulnerability might as well be called a "RST flood"), connection hijacking (by sniffing packets and sending spoofed packets with the correct sequence numbers), and so on. It's also an implementation issue that is largely caused by implementations having loose checking of TCP sequence and ack numbers, or accepting too large of a window of sequence numbers.
I wouldn't say TCP is broken or that some other solution would be much better; it would be tough to design a transport protocol that is still simple (and doesnt use CPU burning hashing/encryption techniques) that wouldn't have these sorts of vulnerabilities (especially since it's so easy to spoof IP packets); calling this vulnerability severe is like screaming that highways are fundamentally unsafe because someone could point their car the wrong way and start smashing into oncoming traffic.
-fren
"Where are we going, and why am I in this handbasket?"
Service providers on the other hands, must protect their routers because the BGP protocol used to distribute Internet routes between them, massively uses TCP. And when routes go missing, it is hundreds if not thousands of routes to your favourite places that go unreacheable.
The problem in the case of BGP is made worse by dampening, i.e. keeping the flapping routes out of the routing table for a certain amount of time (up to several hours). BGP routes dampening is not always configured. A determined attacker with this knowlege would be able to knock large portions of the Internet offline for hours.
I happen to work for a large, nationwide backbone. We've known about this for about a week now. BGP, configured without an MD5 key (as is usually the case) is extremely vulnerable to this exploit. This is the reason for the top-secret effort in the past week to MD5 all peering sessions, both internal and external on most major networks worldwide. Without this, it's trivial to exploit, in fact we already have source code provided by the NCISS. Input a few IPs and BGP's TCP port number, and wham you take down a peering session. For those that don't understand what this means, prior to the security changes that have been implemented in the last week, the global internet was largely susceptible to this flaw in such a way that major portions could have been taken offline easily. A priority was put on this within the intra-NOC communications channels that exist that has never been seen before to lock this down before the public knew about it. We were embargoed by DHS to not release the information until tomorrow.
3.2.1.4. TCP RST/FIN/FIN-ACK
The article is being presented at CanSecWest, and is called "Slipping in the Window" by Paul A. Watson. I have two friends at CanSecWest, I've asked them to attend and report back what the feeling is.
NANOG members are talking about it, and several regional Tier-1 players have already issued customer notifications.
This exploit goes up against TCP connections that have been established for long periods of time. i.e. not web connections. The most prevalent would be BGP peer connections, which can be up for days on end easily. Without having read details, or the paper itself, by forging packets of BGP peers with adjusted window sizes, you can cause a router to reset (possibly hang, depending on IOS or JunoOS version, not sure about this) it's BGP peer connection. If you were doing eBGP and had your own AS, a directed attack against your gateway routers could force flapping, which would cause route dampening, and lead to denial of service.
What you need to do, is contact your ISP if you are an enterprise network admin, and establish MD5 authentication on your BGP sessions. Check with Cisco or Juniper and find out if your code will drop non-MD5 BGP packets directed at it. An ACL won't do, the attacker would forge the src-ip of a known peer.
This is a completely non-trivial attack to coordinate. You need to know the IP address of the BGP peer of a customer, or the route reflector, and then get the IP address right in an attempt to bypass ACLs and get the BGP session to hang. eBGP multihop means that IP could be any number of routers, and unless you have inside info, you don't know what it is.
Potentially, looking glasses could be used to mount attacks at NAPs or other peering points, but again, I think the major players will be ready for it very shortly, and will spend most of today (if they are any good) coordinating with legal teams to slam the shit out of any forged sessions they see, and start cooperating to run traces with other providers.
If I could editorialize one moment, none of this would be an issue if providers took better care to implement anti-spoofing techniques. Forged src-ip addresses are the bane of security. Most of these attacks don't care about 2-way communcations, they just want to reset connections. Spoofed src-ip lets them do that. Rant off.
Real quote.
God Bless America. Why? Did it sneeze?
In a quickly following press release, Bill Gates adds:
I am a lonely man living on the Galapagos Island. I use TCP/IP over carrier pigeon to communicate with a Nigerian who has promised my great wealth in exchange for securing funds in the First Galapagos Bank, of which I am owner/ceo/clerk, and janitor.
/obscure humor (Does this make me a Galapagos Spammer?)
I suspect someone is interupting my data stream and keeping the replies and account numbers he has been sending me in regards to my money. This vulnerability proves my theory. I am in desperate need!! How can I prevent this!!
Anyone willing to help I will share my wealth with.
The NISCC articles explains things clearly. Nobody needs any more information. Besides, this "new" attack was already known. People just didn't realize how easy it is.
Here's a link to US-CERT's TA04-111A on this topic.
As they state, there is a simple solution: TCP MD5 Signature Option with BGP. Any ISP worth their salt will already be doing it. The rest will learn the hard way.
.
This has been supported in Cisco IOS way back since ~1998 in IOS 11.2
Read the BGP "Bible": Internet Routing Architectures or look at any best-practices guides which will state that TCP MD5 sigs should always be used with BGP.
Or search CCO:
router bgp 109
neighbor 145.2.2.2 password v61ne0qkel33&
It's just a single line that has to be added to both peer sides.
The issue described in this advisory is the practicability of resetting an established TCP connection by sending suitable TCP packets with the RST (Reset) or SYN (Synchronise) flags set.
The packets need to have source and destination IP addresses that match the established connection as well as the same source and destination TCP ports.
The fact that TCP sessions can be reset by sending suitable RST and SYN packets is a design feature of TCP according to RFC 793, but a reset attack is only possible at all because the source IP address and TCP port can be forged or "spoofed".
Although denial of service using crafted TCP packets is a well known weakness of TCP, until recently it was believed that a successful denial of service attack was not achievable in practice. The reason for this is that the receiving TCP implementation checks the sequence number of the RST or SYN packet, which is a 32 bit number, giving a probability of 1/232 of guessing the sequence number correctly (assuming a random distribution).
The discoverer of the practicability of the RST attack was Paul A. Watson, who describes his research in his paper "Slipping In The Window: TCP Reset Attacks", presented at the CanSecWest 2004 conference. He noticed that the probability of guessing an acceptable sequence number is much higher than 1/232 because the receiving TCP implementation will accept any sequence number in a certain range (or "window") of the expected sequence number. The window makes TCP reset attacks practicable.
Any application protocol which relies on long term TCP connections and for which the source and destination IP addresses and TCP ports are known or can be easily guessed will be vulnerable to at least denial of service attacks
Saying Java is nice because it works on all OS's is like saying that anal sex is nice because it works on all genders.
There is a new Internet draft addressing this issue.
A recently published I-D (here) claims 200 seconds is sufficient time for a broadband sub to successfully attack a TCP session, provided their ISP doesn't use egress filtering (and way too few do so).
This is rather serious. Whether you personally aren't susceptible is irrelevant if your upstreams are.
Note to netadmins and sysadmins: block packets with source IPs that are not valid for the interface they came from! Geesh!
In Aug 1998, RFC 2385 came out with protection of BGP with MD5 signatures. Using MD5 sigs will defeat this attack.
This is a well known issue with well known solutions. If the infrastructure is at risk it is because ISPs haven't been doing their job and following best practices.
-weld
There is a new vulnerability that will cause every GM vehicle and cause your children to cry. Vandals can place 1 domestic house cat into the fan and cause the fan to stop and under some cases, cause the vehicle to overheat. This was previously written off as house cats are usually soft ans squishy and have little effect on the powerful fan but Joe Shmoe PHD realised that many house cats have colars that are pretty tough for the fan to digest. Car experts say this is a serious problem and will be dealt with in a serious manner. Suggested work around is to keep your cat tied in the house, and to drive a bicycle instead.
Saying Java is nice because it works on all OS's is like saying that anal sex is nice because it works on all genders.
Maybe I missed something in the advisory, but this sounds like a good old TCP reset attack...
You did.
The news here is that you no longer require the sniffer, because you don't have to know the exact sequence number. Now you just have to be kind of close. How close apparently varies in size amongst vendor implementations.
This came up on the linux-kernel mailing list two years ago during a thread on TCP MD5 stuff to avoid this very problem. Why is it just now making a splash?
This post from Alan Cox covers it nicely. Also see the rest of the thread.
For us, those issues are 1/50000 smaller than they are for other vendors.
So, they are 50,000 times bigger ?
Besides the fact that their little kitty bones could get into the works and actually stop the fan.
I'd say this is a real threat. We need to protect our SUV's from the mobs of 1337 haxor kitten terrorists! I propose bombing __insert country here__, under the guise of giving them democracy and freedom, and simultaniously pass some laws at home which take away some of our freedom.
Huh?
Suicide terrorist kitties?
Al-Kitty?
Yes, that was corny, and no, I couldn't resist.
vi ~/.emacs
Yep, sure, however, if you flood the network with your packets, it will be probably noticed soon. Also in order to flood the network, you need a fast connection to the attacked host, reducing the problem to the immediate neighborhood of the attacked host. That's why this attack is not very practical to perform and the impact on most normal mortals is low (except for the BGP issue, which could take out your upstream router)
The problem with BGP, which is mentioned in the original article, is that it has a particularly bad failure mode - when a BGP session goes down, it is very expensive to restart it. To top it off, BGP uses very long transmission windows (because it transfers lot of data and that is more efficient with longer windows) and that makes it easier to squeeze-in the spoofed packet. This is quite messy affair, when it happens.
However, if somebody attacks your favorite web site in this way, I doubt that you are even going to notice it, since http sessions are stateless and comparably cheap to establish.
So, I think this is just a big scare for nothing, it is mainly BGP issue for now. It affects just people who know how to fix it (and are fixing it right now) and the machines involved are relatively few. Unlike some Windows RPC exploit which unleashed a massive world-wide worm in few minutes.