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 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.
Might this be THE final topic to bring IPv6 to a wider attention?
I'd hope so...
you can exploit slow start too. was published last year for some conference. The paper is called "The Shrew vs. the Mice and the Elephants" and is by Aleksandar Kuzmanovic and Edward W. Knightly
I write code.
NISCC slashdotted so fast... what would happen in a real emergency??? when everybody really wants to know...
Donald 'Duck' Dunn: We had a band powerful enough to turn goat piss into gasoline.
This is really just trying to get someone's name out on the security sites. Currently, in a decent TCP/IP implementation, you have to know the source and destination IP's, the source and destination ports, and the sequence number. Now, some of those are fairly easy to determine, but others like the source port (assuming connecting to a server) and the sequence number are not. (BTW, I do realize that in some crappy implementations the source port is easy to guess, but whatever) You would need to be able to sniff the actual connection. And in all honesty, if you can sniff the connection, there are much easier ways to cause a DOS (for example, bringing down the interface).
Best slashdot comment
BGB disruption. This is worse than you can even guess. I anticipate this will lead to effective phishing scams, and other things.
The danger is that by killing off the legiment routes to a host, somebody with a cracked router can then claim to have the legitament route to the host. Which of course, it doesn't. So, quite effective traffic redirection from the internet to a malitious web server.
The big guys already knew about this.
The script kiddies just found out.
If you're a script kiddie and you try to exploit, you won't get anywhere, and you'll get arrested.
If you're a serious hacker, you won't do that.
If you're a serious cracker, you either already have done it, or you've moved on to another, juicier target, because there's no pride in going in after Yahoo! news stories.
So this is just a way for the FBI to track down script kiddies.
"Piter, too, is dead."
At my corporation, they run a product which listens for P2P software like Kazaa and exploits this vulnerability by sending a spoofed RST to shut down the service. I had to patch my TCP stack to check the ACK # in order to keep my FastTrack client leeching porn.
Sounds like IETF is zeroing in on these guy's business model. Good. The anti-P2P vendors will probably catch up by spoofing both numbers, but they will have to ensure that their RST beats the actual packet there, which is tricky.
Hey, the 3 way handshake works for establishment, and it'd solve this problem if we implemented it for disconnections.
x wishes to close connection, y checks this by sending random bits and a check request, x sends these bits back to ensure that it really is x wishing to close it, and voila.
Perhaps this might be a good time to encourage everyone to move over to IPV6.
Does it go on forever?
There is a new Internet draft addressing this issue.
Really, though. If you need to calculate a valid offset from the ISN, big TCP-window sizes are of advantage to the attacker.
To quote from the announcement:
BGP-4 relies on persistent connections, with huge window sizes.
"Flyin' in just a sweet place,
Never been known to fail..."
Let's say we ALL did over night. Given its new-ness you'll have 20 bugs to kill in under 18 months. I prefer the gradual approach.
Obama's legacy: (N)othing (S)ecure (A)nywhere and (T)error (S)imulation (A)dministration
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
Not all of IPX, but at least the numbering scheme felt halfway thought out: full addresses were 80 bits long, comprised of 32 bits of network address and 48 bits of node addresss, the latter almost always being the device's MAC address (which is a delicious hack for ARP tables on ethernet networks).
/24 space for IPv4.
The 48 bit node address space would make it easy to have large single-subnet LANs without dealing with multiple subnets/NAT/routing, and the network portion of the address space is as large as the entire
The rest of IPX was kind of a kludge, but I liked the numbering system.
Gore took the initiative in creating the Internet by taking the initiative to support the legislation required to get it going.
And just how, exactly, did he do that? He wasn't even in Congress at that time. IIRC he was in college, or high school, or something.
nothing in his statement could be properly construed to imply such
Look it up. He clearly implied that he was present at the creation of the Internet, and actively made it happen -- which is clearly a falsehood.
Yes, he apparently DID do some things to help the Internet while in Congress -- for which he deserves credit -- but the Internet already existed; he sure as hell didn't 'invent' it.
And it has nothing to do with which team (Bush v. Gore) you were rooting for. Everyone SHOULD be able to rationally sort out the facts regardless of ideology. Of course, the Gore people still have trouble being rational, but that's another thread....
In times of universal deceit, telling the truth gets you modded -1 Troll
As a side note, all the major sites with several BGP peering points have recently started using MD5 authentication. We have been updating all of our peering sessions over the last week or so.
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.
Until this week, yes. Of the ~250 peering sessions we have, there were 20 that had MD5 keys on them. This was the generally accepted practice until last week.
Okay I do not know much about BGP, but the MD5 on the peering session is happening within the BGP, right? How does that make the underlying TCP connection more stable or less vulnerable to this attack? Maybe I am wrong about the design of IP-layers, but changing the upper layer should not fix the lower one ... And attacking the lower one will affect all higher ones. Or does BGP with MD5 checksums no longer require a persistant TCP connection?
Either I have a stupid day or I do not understand the benefit of putting MD5 into BGP.
To make an end user example: If I have a very long POP3 session (because somebody zipped the google cache and sent it by mail) I would be vulnerable, because this long lasting session could be attacked. Then I loose the session and have to establish a new one. Building a checksum into POP3 won't change much about that.
Nils
But IPv6 makes encryption (and "signing") possible so you can't spoof those packets. TCP is above IP in the stack ya know?
Or did _I_ miss something?
Out here who took notice that this is more or less the same old hat trick of resetting connections that has been around
SINCE THE CREATION OF TCP/IP?
*Duh*
c'mon, script kiddys have been throwing packets to reset connections for years.
Same old trick, new aplication. Yes, now we all have the ability to throw a good fingerpoint at a vendor or two and say shame on them, and make some great BSD-is-safe-again! remarks.
Moving right along...The only people 'vulnerable' to this are people who don't configure routers/firewalls or BGP's properly to use hashing, or no-brainer spoof blocking at the forefront, etc.
And guess what that means? They should have paid closer attention in class. Darwin works in more places than just the gene pool.
My new top secret key -> C>N|KB
From the advisory:
We told you not to deploy NAT because (among other reasons) it would break IPsec authenticated header (AH) mode. You did it anyway and told us we were pedantic academic pinheads.
You deserve what you get.
--
jhw
unfortunately zebra doesn't support MD5 on BGP. Now what? 'upgrade' to cisco?
AC
In practice, these attacks are quite tricky to perform, because they require good timing and quite a bit of skills
Well, they require a packet with the right sequence number to hit in the right time period.
Since there's a window of accepted sequence numbers, it really only requires a shitload of packets with likely numbers. Send enough good guesses and one will hit at the right time.
Like a race exploit, I don't think this requires 'good timing', I think it requires enough attempts to reduce the odds - many will fail, but one may succeed.
Code or be coded.
This is a good point - is this attack still possible in IPv6? If not, could this be the killer event that make the switch seem like a good idea to all the companies that have been refusing to change.
(if the hack is still possible in IP6, then I can only ask *why*??, since the basic principles of the flaw have been known for a long time)
(Spudley Strikes Again!)
Lets go for starters, BGP packets unless multihop should have a TTL of exactly 1 and come through a point to point interface.
First of all, it's trivial to deliver a packet to a certain host on the Internet so that the TTL on the packet is exactly 1 (just do a traceroute and send out the packet with a TTL to match the number of hops). Second, I would say that many important BGP sessions are NOT accross point to point links, they are over Gigabit Ethernet at IXP's.
Basic anti-spoofing on each side will stop any packets that cleam to be from the other end of that interface from comming in any other interface
Please explain to me how you would do this on a Cisco 12000 with Engine 0 or 1 linecards and still maintain line rate. In fact, please explain to me how this can be done on any Cisco at all. (URPF doesn't protect against this.)
BGP does support preshared keys as well though I'm not sure if that will stop this attack as it's more to prevent session hijacking. I dont see a 'fix' for this comming out besides normal security settings.
I'm not sure either. I'm aware of the enormous BGP MD5 authentication setup rage that has been going on over the past week and while I think this is a good effort I'm not entirely sure if it will protect against the RST attack. BGP lies on top of TCP so if you are able to kill the underlying TCP session I don't think MD5 authentication protects against this. Anyone care to enlighten me?
The best thing I can think of so far is tweaking windows sizes etc. and do ingress filtering on your network where possible.
From my daily reading it looked like the recent mailing regarding the Rose attack Which could affect nearly as many systems as this TCP vulnerability. With two vulnerabilities of this extent, and their relative quiet reception by the security community I don't think there will be much of a push to fix this problem, while the k1dd13s go to work acquiring proof of concepts.
So, those 20 people who use bsd as a network *client* are somewhat less likely to have their tcp-connections successfully attacked as those who use predictable source-ports. (still not 48000 times safer as Theo writes, predictable does not typically equate "100% guessable with 1 try")
This "vulnerability" is kinda lame really. Previously, people who didn't think about it very much, assumed that since to reset a TCP-connection you need to guess the sequence-number, the chance of successfully doing so would be no higher than 1 in 2^32.
This "vulnerability" only points out that infact tcp-implementations will accept as valid any sequence-number between $CURRENT and $CURRENT+$WINDOW_SIZE.
So, instead of needing to try 2^32 times, you need "only" to try (2^32)/$WINDOW_SIZE times. Still fairly hard under typical conditions.
Window-size is however typically proportional to bandwith and inversely proportional to delay, so it'll be easiest to exploit on a tcp-connection that has high bandwith, and high ping-times. For example any connection that goes over satelite. (those of you that knee-jerk and think that high bandwith and high ping can't coexist should go reread first-year networking-curriculum.)
You didn't before either. Guessing sequence numbers used to be much easier...
And BTW, guessing sequence numbers based upon the predicitability of different vendors' TCP stacks is also quite old.
About the only new thing here is that some moron reporter decided to write a fire and brimstone story about this well-known issue.
Does everybody remember back when CNET reported that Mozilla was going to become a full office-suite? Yes, that who article was based on one random person posting that (one-line) suggesting to the mailing list. Many reporters really are pure slime.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
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.
{{.sig}}