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?
Tony had discovered this vulnerability about a year ago. Luckily it was first discovered by an intelligent and ethical IT security guy and not some unscrupulous hacker. He has quietly worked with vendors during that time helping them come up with a solution.
Move along, little to see here.
the chance of causing arbitrary BGP route flaps went from 1:2^32 to 1:2^2 and you say there is nothing to see here?
you must be a windoze user if this doesn't faze you.
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.
... since TFA goes on to say the vulnerability explicitly affects "long-lived" TCP connections, not the POP3 / HTTP / SMTP that Joe User relies on. However, for businesses and security wonks this is a potentially big deal.
Oh, right. Copy and paste job gets moderated +5. That's great.
My other processor is big-endian.
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.
My understanding is that with this method it no longer "takes awhile to probe for the magic number to reset the connection"; the one article I read said he could do it in just a few guesses. By being able to do that, couldn't someone effectively keep a router in an almost permanent state of reset, resulting in a DOS?
(Note, I don't really know anything about this stuff...)
The scary thing is, he might not be.
The recv window is an int. Thats 2^32. The window size is unknown, but you can guess that its say... 65k, thats pretty big. Even at that rate, youd have to go:
//Test vulnerability with *this* number..
for(int i=0; i<0xFFFFFFFF; i+=0xFFFF )
{
}
This doesnt seem too bad, this is only 65,000 guesses, but you have to keep in mind that the window is moving the whole time, so you might accidentally skip over it, or if your not going fast enough, never reach it! (And, 65k is a pretty damned big window, I havnt tested any long term connections, but chances are it wont get this big).
-Bill
-Bill
When I read this I had to laugh. It's an entire technical article on a "vuln" that has been known since the bsd4.4 days. Predictable ISN's are bad...enter windows. Tcp/ip stacks are not created equally, this is how nmap fingerprinting and p0f passive fingerprinting work. Anyone who has read tcp/ip illustrated by richard stevens would also be aware of this, btw that author is dead. If all the core internet routers were windows boxes this would be a big issue and the internet would have been DDoS'ed into extinction years ago. I would think that cisco routers ISN's aren't nearly that bad and in any case it's no where near as bad as the doomsayer(s) claim.
:(){
Maybe I missed something in the advisory, but this sounds like a good old TCP reset attack.....which is neither a new or novel concept. People have been doing this for ages with a sniffer and a packet generator.
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.
Hence this is an implementation issue that can be patched in TCP stacks.
Ohhhhhh, all we have to do is upgrade the code in all BGP routers and major webservers on the entire internet! Do they have "Windows Update" for Cisco IOS yet?
Seriously though, it would help to have a list of specific implementations which use the large window.
So I expect you'll see a distributed effort, using viruses. (shudder)
tasks(723) drafts(105) languages(484) examples(29106)
I read the paper, which is nothing more than a rehash of what every security person already knows about: tcp sequence guessing.
.02c
This issue erupted on the freebsd irc chat, and I had to kill it by posting this linkage: http://lcamtuf.coredump.cx/newtcp/
As you can see TCP sequncing is fairly random in most of the IP/TCP stacks out there in commercial use. The reasearch paper mentioned in the article only applies to the OS's in the above link that dont' have near true 32bit randomness.
The feasability of overcoming realtime 32 sequence guessing is insane, however non-zero. just my
It isn't a lie if you belive it.
He made a sweeping claim that he "took the initiative in creating the Internet" that was clearly intended to be taken as it was, and just as clearly intended to be deniable if called on it.
It's not a "myth" that he did this, nor anything to be proud of, if you're a Gore-ite ... I notice Gore-ites sure get uncomfortable about it.
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*
However there is a developer being paid to work full time writing SMP support for OpenBSD. He expects to have a working implementation by 3.6 or 3.7.
The policy of the United States is worse than bad---it is insane. -- Ludwig von Mises, Economic Policy(1959)
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.
More likely they want to make sure they're understanding the issue correctly and write up a good explanation.
My research on the vague news note lead to the following information:
Routers using BGP (Border Gateway Protocol) use
a technique called dampening to control amount a traffic a link generates.
Details:
When a link goes up or down, updates must be passed to any router using such link. Those updates bubble up if a link goes up and down to often causing unwanted high levels of traffic. A link gets dampened when it's activity (going up or down) is ignored for the reason mentioned above.
Exploit.
A false (link up/down) update message may get a healty linked damped by a router or group of routers halting all traffic through such link.
Of course, non of the above has to do anything w/
tcp protocol but a lot with Routing Protocols which are the very foundation of the Internet.
I may be not be on the right track.
Cheers.
- these are not the droids you are looking for -
I think you're getting a bit over excited.
If people have cracked routers there's nothing to stop them already from adverting routes to the global routing table, claiming to have better path to "phishing site" than the router currently has for "proper site"
This exploit isn't a crack. All it means is that the hacker can take down a number of BGP sessions if he so wishes.
The sky is not falling, most ISPs with any clue have been working on this for the last week already.
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.
Tss. Juniper is full of it. It clearly is an implementation flaw, not a specification flaw. As pointed out in an earlier post RFC-793 allows for and recommends checking ACK numbers as well as SEQ numbers when validating a RST, but apparently not many implementations do so (though they still may have other preventive measures that rules out the brute-force-RST scenario).
I don't know quite how to respond to this without it being taken as a flame. Here's the best I can do. If you truly want OpenBSD to succeed as an operating system on a grand scale, you're going to need to stop excusing it's weaknesses and admit those shortcomings that are obviously bad. SMP support is absolutely required for any widespread success in the enterprise, as well as the other areas mentioned in another reply to this post. You need to understand this if you want to truly have a dialogue on why someone will/won't use OpenBSD.
"A man talking sense to himself is no madder than a man talking nonsense not to himself."
I am not an "OpenBSD zelot"; I use OpenBSD on a few servers and hence am subscribed to the misc@ list. This was recently discussed so I thought I'd fill the poster in.
All of the software you mention, while important, isn't what's used on a majority of systems (and more importantly isn't what the developers use their systems for). Many many more systems operate web servers, routers, file servers, and mail servers: general work horse stuff. That's what OpenBSD likes to focus on (because that's what the developers use it for). Hence SMP isn't a huge priority. Most of the developers don't work on OpenBSD for a living; they just code to solve there own problems (which by necessity are in the domain of what they use the software for). If this happens to solve your problem too that's great; if it doesn't well you do have the code.
Furthermore, all of the software you mentioned is corner case, no where near common. How many bank computers and render farms are there compared to the number of web servers, mail servers, and routers?
As for databases, most databases are more in need of RAM and fast disks then CPU. Those that are CPU hogs are often poorly designed. For those that actually do need multiple CPUs, let me remind you that there is no such thing as an all-in-one-solves-every-problem-every-time tool: you proably don't want to use OpenBSD for that anyway.
None of this changes my claim that SMP is a (useful) hack to squeeze more performance out of today's technology for those who just can't wait (and are willing to pay through the nose).
The policy of the United States is worse than bad---it is insane. -- Ludwig von Mises, Economic Policy(1959)
Yeah. The biggest problem here is the ease with which one could DoS the BGP-4 protocol.
Actually, if any backbone providers are getting a BGP feed and not doing any type of ingress/egress filtering they are asshats and deserve to be knocked offline, if only so that their Cisco engineers can be fired and they can get some compentent help to fix the problem.
Really, this issue is not going to take the internet backbone down. Most of the major backbone providers are smart enough to know that you don't just accept BGP traffic on any interface that claims to be from the IP address of your peer.
"When the president does it, that means it's not illegal." - Richard M. Nixon
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.
one part of the problem is looking glass sites. they are great for admins, but they do tend to leak out some information that could be used to do just this sort of attack. go check these sites and look at the 'bgp summary' pages and you will see the source and destination IP pairs for the peering sessions. no source or destination tcp ports, but you know one is 179. That's still alot of combinations to try but NetSky-AJ.bis could have a field day with this type of DDoS. If the viruses have room for messages in 6 languages, you can bet they can store plenty of 4 byte IP addresses to lauch this kind of attack. You know how long it takes to flush 125k+ routes and reload them? Propagating all those updates to other peers would quickly make things worse, and dampening would exacerbate things further.
:)
better double check those ingress and egress filters.
Routers don't usually do a lot of TCP themselves, except SSH or telnet access for management, but the one big exception is the BGP protocol that routers use to connect to each other, primarily at the interfaces between carriers. The BGP sessions stay up for a long time, and killing them tells the router that it's no longer talking to its neighbor so it should go find a different route to get to that network, which is really really annoying. On the other hand, BGP has options to do more checking on BGP messages before accepting them, and carriers that do spoof-proofing to prevent their customers from forging packets have less risk, and carriers that block packets addressed to their routers accept from approved destinations are much safer.
Some customer connections to ISPs use BGP, especially if the customer uses multiple ISPs, though most are static - these could be subject to spoofing by somebody inside the customer's network, if they're not careful. (The customer could be an ISP, or they could be a regular customer with an employee who has next month's interesting virus.) So customers who don't want to get thrown off the net should probably be careful to do good firewalls to keep their own users from spoofing their connections.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Reading through the comments, the scariest thing about this thread isn't the original article...
It's the comments posted by a fairly experienced bunch of geeks.
The misconceptions illustrated throughout this thread demonstrate how badly some aspects of the Internet, TCP and protocols are misunderstood by people who think they have a full working knowledge of these mechanisms. (Some posts...Other posts admittedly correct some errors)
It's because of these people who *think* they know what's going on while working in the industry that the true risk grows, because hostile hackers will always find a home in the huge gaps left by their ignorance.
Ignorance is more dangerous in the long run than apathy. Apathy can change.
Apologies that this post is slightly OT, but it's relevant to the theme.
GrpA
Enjoy science fiction? "Turing Evolved" - AI, Mecha, Androids and rail-gun battles. What more could you want?
There is a simple solution - just use pair of any NON public IP addresses on both sides of BGP links. This addresses are not published (not propogated via BGP itself) and nobody is able to send packets to it besides BGP peer partener. Problem exists only for stupid IS staff.
So the routers are now supposed to deny access based on a send history? It would be easier, cheaper, and more reliable to just turn on the fisking anti-spoof stuffs at the ISP level. An ISP knows what IPs it has. Anything coming from inside their network claiming an IP from outside their network is trivially detected and should be just as trivially discarded.