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.
It doesn't save anything. When someone exploits this and takes out 90% of the Internet's routers, you're screwed no matter what.
It definitely makes a good argument for both OpenBSD and proactive security auditting. But it doesn't save the day.
I'm no expert, but wouldn't a security problem with TCP be completely unrelated to IP?
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.
Good and funny :) but I think what they mean is that more details would give more info for exploits, so their sitting mum til things can get solidified a little more.
Well, that means our home PCs aren't likely to get exploited by this. However, if our ISP's router gets exploited, we're knocked offline and our PC isn't as useful as it used to be.
The threat here is a DOS aimed at a few things that we don't want to see go down.
No, its not a problem that is software-specific. They are utilizing a 'flaw' in the design of TCP by spoofing the sender's IP address and port, *AND* guessing the recvwindow number!!
:P
The reason it only affects long-term connections is because it takes awhile to probe for the magic number to reset the connection, and ALL this does is reset the connection, nothing more.
This whole thing is retarded, if you know enough about TCP this exploit was already on your mind and forgotten because its stupid.
-Bill
-Bill
So, it's simply another type of denial of service. A TCP Reset packet can be faked, which will result in a legitimate open TCP connection being closed by a third party.
It also assumes a few of things.. You would need to be in the network route, or have some other means of establishing the sequence numbers for the connection. You would also need to be in a network that does not filter out improper source addresses (which some networks do.. but more should do) to allow your spoofed packet to get through.
So, the problem boils down to a low bandwidth method to DoS TCP connections. It does not give a method to hijack the connections, or otherwise gain access to data.
Anyway.. Clear IP connections are very open, and completely based on trust. Any sensitive communication should be tunneled inside a VPN, where it would not be vulnerable to this type of attack. (A real IPSec tunnel would not be vulnerable - as it does not use TCP. "SSL VPNs" use TCP as a transport, so they might be open to DoS.. Stick with the security of IPSec for best results.
It is indeed a problem with TCP but, it is in no way new. Many people have relied on this "vulnerabillity" for years. This is the technique that many firewalls implement in order to terminate undesirable sessions.
This vulnerabillity impacts the applications that are unable to handle session interruptions. BGP is such an appilication but, its impact on BGP is critical because this attack could seriously impeed BGP and since the internet backbone relies on BGP such an attack could covceivably shut down the internet. This is a known vulnerabillity in BGP, as you said, and it is surprising to me that BGP has not been modified to prevent this from happening.
By and large most applications will be able to deal with this and only minor annoyances such as DoS will occur.
As for earlier posts about OpenBSD being immune, I am very eager to hear how that is possible. No matter what the implementation, it is still possible to reset TCP sessions. This means that OpenBSD is still potentially vulnerable to DoS attacks.
Provided that BGP is modified to make it more fault tolerant, I can't see this problem with TCP being anything more than a short-lived niusance. I'm sure however that many people will try to use this as leverage to force IPv6 migration however, I believe that it too is vulnerable.
Note to netadmins and sysadmins: block packets with source IPs that are not valid for the interface they came from! Geesh!
Now I what read up on TCP/IP and my memory isn't that good, but isn't it the TCP part which a problem, mening that switching to a different IP protocol won't help you at all. IPv6 is as far as I understood it, only adressing, the TCP stuff is the same... maybe not.
What I find most worrisome is this:
"BGP, configured without an MD5 key (as is usually the case)...."
So, critical infrastructure, worthy of "a priority...that has never been seen before", is routinely run unsecured? *shivers*
Maybe it's about fucking time ISPs started using egress filtering. At the very least, there'd be an order of magnitude less crap (smurfage, etc) if ISPs dropped spoofed source IP packets before they got to the backbone.
OK, so the ability of any skript kiddie to spoof and insert a BGP update is a pretty fucking huge mess. But "pretty fucking huge" it may be the only kind of mess that motivates the clueless fucktards pretending to be "ISPs" these days.
2. This is not at all the same thing and in no way similar other than the fact "it uses TCP".
3. This vulnerability should not be called an RST flood. That would confuse it with a SYN flood which works totally differently and is much simpler. This should be called a broken window attack or something.
After noting all the other kinds of irrelevant TCP attack and reading up on this rather serious one, you wouldn't say it was broken? Could it be that, like everyone else including me, you never realised it was broken because you never looked close enough? It's called IPSEC, it's secure on the IP level up so TCP is encrypted over it. The simpler way to increase security would be to maintain current window size but increase the sequence number field to 64 bits wide. This would make it nigh-impossible to find where the window is sitting. Highways are fundamentally unsafe. They're full of retarded people shunting 3 ton hunks of metal around at speeds they're not comfortable with. But your point is void because people would not do that as they'd die as a result and kill a lot of people. I don't think a kid doing a TCP RST attack really needs to be that dedicated, and this could cost businesses millions of dollars if they don't wise up to it sharpish. Most people who'd took even a short course in networking would be wise to it already.
The best defence against this? Simply check for a stream of RST packets. They dont come in huge bundles with incrementing sequence numbers often. Detect that signature, block IP, sorted.
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.