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.

OpenBSD is safe?

This just hit the misc@openbsd mail list:

Date: Tue, 20 Apr 2004 12:57:12 -0600
From: Theo de Raadt <[e-mail]>
[snip]

In the OpenBSD case, this is something not to worry about. For what
they discuss, OpenBSD handles this extremely well.

We'll explain more in a week or so.

It sounds (again) like proactive security auditting saves the day!

Re:OpenBSD is safe?

What about proactive spelling auditing?

NISCC slowing, here is the meat summary of article

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

Re:NISCC slowing, here is the summary of article

BTW, I pasted this here mostly as damage control. I know how some people (and yahoo apparently) like to fly off the handle and claim the world is ending without bothering to even RTFA. You wonder why some people are Afraid to use a computer. If I wrote for the auto industry and intentionally tried to scare the shit out of people Detroit would sue me off the map.

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.

Re:NISCC slowing, here is the summary of article

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.

Re:NISCC slowing, here is the summary of article

Suicide terrorist kitties?

Al-Kitty?

Yes, that was corny, and no, I couldn't resist.

Re:NISCC slowing, here is the summary of article

"Al-Kitty?"

You're not mangling your Arabic-to-English transilteration enough. It would probably look more like "al Qiddy"

Re:NISCC slowing, here is the summary of article

And putting Al-Kitty through said fan will result in Al-Gore.

Re:NISCC slowing, here is the meat summary of arti

Note: that's 1/2^32 (substitute your own favorite exponential syntax), not one in two hundred thirty-two.

Re:NISCC slowing, here is the meat summary of arti

Actually, this is just a variation on an old attack with sequence number guessing. Some OSes have a very poor generator for these numbers (even though the vulnerability is known for ages) and it is possible to exploit it. Probably the most famous attack of this sort was Mitnick's break-in into Shimomura's machine ten years ago.

In practice, these attacks are quite tricky to perform, because they require good timing and quite a bit of skills, so they are quite rare. It is far easier to just exploit some common buffer overflow than this.

The impact could be not only DOS (by resetting the connection), but you can do also packet injection with potential for total system compromise. However, if the protocol used is encrypted (in Shimomura's case it wasn't, if I am not mistaken, Mitnick attacked rsh or rlogin), then the DOS is probably the worst thing that could happen to you. The encryption will reject the bogus packets, if properly implemented.

So, keep calm - this was here since at least 80-ties and there isn't much that you can do against it, except to use encryption. You can only hope, that your system vendor will decide to make their TCP stack less vulnerable (not likely to happen, since many systems still ship with the crappy sequence number generator!). Full fix is not possible anyway, unless you want to break the protocol.

Regards, Jan

Re:NISCC slowing, here is the meat summary of arti

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.

Re:OpenBSD is safe?

Great, I guess Microsoft will just have to copy the BSD TCP/IP code again to ensure that their customers are safe ;-)

Re:OpenBSD is safe?

Yeah. The biggest problem here is the ease with which one could DoS the BGP-4 protocol.

The Internet BGP tables are ricketey enough these days - they don't need every other route to "flap"!

Re:OpenBSD is safe?

Some genius modded my post as a Troll. I guess it's because they know so much about this vulnerability, and how the exposure goes up as one increases TCP window-size. ;-)

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:

In a TCP session, the endpoints can negotiate a TCP Window size. When this is taken into account, instead of attempting to send a spoofed packet with all potential sequence numbers, the attacker would only need to calculate an valid sequence number that falls within the next expected ISN plus or minus half the window size. Therefore, the larger the TCP Window size, the the larger the range of sequence numbers that will be accepted in the TCP stream.

BGP-4 relies on persistent connections, with huge window sizes.

Re:OpenBSD is safe?

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.

Re:OpenBSD is safe?

If you are using MD5 encryption that is built into BGP4 that won't help you. That merely will stop route poisoning and such. As long as your underlying TCP/IP implementation isn't authenticating source/destination you can still get hosed.

Re:OpenBSD is safe?

Or it might be that you just read the article, and more or less parroted what a more experienced individual said. Especialy given that anyone who deals w/ BGP on a regular basis knows (or better know) how to secure peering links against this kind of vulnerability.

It's actually quite trivial to do. ebgp-multihop and using the remote host loopback address as the neighbor IP, along with a few small architectural configuration tricks are all that's needed to completely prevent this kind of attack, or, at the very least, minimize it significantly.

Are _you_ going to scan, not only the entire range of source ports, but all those ports times the entire RFC1918 address space? Good luck killing my systems, buddy, 'cause that's what you're in for.

Oh, even with the large window sizes, once you've found all the above, you've still got to find my sequence numbers.

RFC 2385

There is RFC 2385 [ietf.org] titled Protection of BGP Sessions via the TCP MD5 Signature Option. In the first paragraph of its Introduction section it says -

The primary motivation for this option is to allow BGP to protect itself against the introduction of spoofed TCP segments into the connection stream. Of particular concern are TCP resets.

The date of publishing - August 1998, which makes it about 6 years old.

However the proposed option was primarily meant as a quick BGP fixup, which should've got depricated as soon as IPsec got RFC'ed and deployed. It did went standard few months later, but IPsec implementations enjoyed full share of cross-vendor compatibility problems.

With time Authenticated Header (AH) IPsec protocol didn't see much use or acceptance and IPsec slowly evolved (and keeps evolving) into confidentiality rather than authentication layer.

Besides it's an IP security after all, while the RST spoofing is a TCP problem. And one can quite rightfully percieve authenticating TCP with IPsec as an overkill.

Anyhow, long story short - it's a known and rather old problem with handful of existing and equally unattractive solutions. Perhaps this time around it will be addressed better due to the amount of the publicity it's aimed to get.

Re:OpenBSD is safe?

>For what
they discuss, OpenBSD handles this extremely well. We'll explain more in a week or so.

Is the margin of the page too small to explain the wonderful reason why it handles this so well?

Re:OpenBSD is safe?

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.

What details, the info is already out

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.

Re:OpenBSD is safe?

Theo Wrote:
Let me be more clear.

This entire thing is being "sold" as `cross-vendor problem'. Sure.
Some vendors have a few small issues to solve in this area. Minor
issues. For us, those issues are 1/50000 smaller than they are for
other vendors. Post-3.5, we have fixes which make the problem even
smaller.

But one vendor -- Cisco -- has an *UTTERLY GIGANTIC HUGE* issue in
this regard, and as you can see, they have not yet made an
announcement see..

You are being told "lots of people have a problem". By not seperating
out the various problems combined in their notice, or the impact of
those problems, you are not being told the whole truth.

More Theo:
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.

At least one other free operating system incorporated our random port
selection code today..

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.

At least one other free operating system today incorporated the same
changes......

Re:OpenBSD is safe?

It sounds (again) like proactive security auditting saves the day!

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.

Re:OpenBSD is safe?

It doesn't save anything. When someone exploits this and takes out 90% of the Internet's routers, you're screwed no matter what.

But it saves the day for my network of 3 linux boxen in my basement which are s0 K3wl, they r0x! While the Internet burns to the ground I can route packets back and forth with impunity between my 486 laptop and my Pentium II Server!! WooHoo!

Re:OpenBSD is safe?

LONG LIVE THE INTRANET!

Re:OpenBSD is safe?

You just wait until the stock market is driven crazy by all those dotlocals with impossible business plans.

Re:OpenBSD is safe?

...in my basement...

err um, don't you mean your parent's basement :)

Re:Server exploit, not router

If you read the article it'll explain it for you, but basically:

Routers from different AS's talk to each other using BGP4. This protocol uses TCP.

The "exploit" uses spoofed packets, so the router will process them as if it came from their neighbour.

So yes, while the router is mostly "shoveling packets", it learns the direction in which to shovel these packets via the exploitable method.

If you want to disagree, feel free to let all the major tier 1 ISPs who have been busily implementing MD5 authentication on their BGP sessions know their wrong.

Windows also safe

In a press release from Microsoft, Bill Gates states:

All Windows versions from 3.11 to 2003 are quite safe from this exploit, since Windows also supports the famously reliable NetBEUI protocol. In a proactive measure, Windows update will remove support for TCP/IP and ensure that all updated computers have support for NetBEUI only. NetBEUI will once again rule the earth! Take that, Steve! No, not you, Ballmer, the other Steve. The hippe. Woahahahahahaha!

In a quickly following press release, Bill Gates adds:

Woahahahahahaha! Hahahaha! Hahaha! Thank you.

Re:Windows also safe

Ah, come on! I was joking, not trolling for flames. And besides, how the hell was that going to attract flames? If that really was flamebait, it should be modded -1, ineffective.

(Was it the hippie part? Yeah, sure calling Steve Jobs a hippie is flamebait, but this was also clearly a joke. Some moderators are just in a dire need of a blow job.)

Re:Windows also safe

Some moderators are just in a dire need of a blow job.

Nice of you to volunteer, looks like their outlook has improved already :)

Re:Windows also safe

"Some moderators are just in a dire need of a blow job."

And that should be modded "-1, Redundant" but you don't hear me compl...oh..shit.

Re:Windows also safe

Security Update for Windows XP (KBTCPDRM-666)

This update addresses the vulnerability addressed in Microsoft Security Bulletin 666. Find out about more recent critical updates in the Overview section.

File Name:

WindowsXP-MSTCPDRM-x86-ENU.exe

Download Size:

1261 GB

Date Published:

4/20/2004

Version:

666

Overview

This patch fixes criticals security vulnerabilities present in Windows TCP stack.
This patch also add the new DRM TCP extension.
When is patch is applied, your computer will connect to drm.microsoft.com prior establishing any other connection to make sure the requested end point is an authorized Microsoft partner. All rogue packets are now rejected and reported by the Windows TCP-DRM firewall (TM).
This patch also upload the registry key HKEY_LOCAL_MACHINE and all subkeys and values to drm.microsoft.com so we can make sure all software is used according to their end user licence agreements.

System Requirements

Supported Operating Systems: Windows XP

Windows XP Professional
Windows XP Home Edition

More from Theo (was Re:OpenBSD is safe?)

From: Theo de Raadt <[e-mail]>
[snip]

Let me be more clear.

This entire thing is being "sold" as `cross-vendor problem'. Sure.
Some vendors have a few small issues to solve in this area. Minor
issues. For us, those issues are 1/50000 smaller than they are for
other vendors. Post-3.5, we have fixes which make the problem even
smaller.

But one vendor -- Cisco -- has an *UTTERLY GIGANTIC HUGE* issue in
this regard, and as you can see, they have not yet made an
announcement see..

You are being told "lots of people have a problem". By not seperating
out the various problems combined in their notice, or the impact of
those problems, you are not being told the whole truth.

Re:More from Theo (was Re:OpenBSD is safe?)

For us, those issues are 1/50000 smaller than they are for other vendors.

So, they are 50,000 times bigger ?

Re:More from Theo (was Re:OpenBSD is safe?)

>> For us, those issues are 1/50000 smaller than they are for other vendors.

> So, they are 50,000 times bigger ?

No, that would be 49999/50000 as big.

Re:OpenBSD is safe?

I guess they were smart enough to implement the new Evil Bit added to TCP last April. Those OpenBSD folks sure are forward thinking.

Re:OpenBSD SMP

Combine that with the fact that almost all of the programs used on a modern UNIX-like system arn't CPU bound and it's easy to see why SMP took a back seat to more "interesting" issues.

Wrong. Very wrong. Are you anaware of this field called "banking"? What about "financial trading"? These firms have huge portfolios and run and re-run various models on them. At night, the systems have to run various "end-of-day" scripts and reports, which take CPU-hours to complete. Most of this things run on Unix...

There is also on-the-fly image manipulation, and the scene-rendering done by fleets of Unix machines. The more CPUs each such Unix machine can fit, the better.

Then come databases -- depending on the queries (with joins and orderings), DB-servers can be CPU bound and appreciate multiple processors when available.

What about PVM [ornl.gov]? What was it -- and similar packages both free and commercial -- written for? What about this proverbial "beowulf clusters"? Of course, it is much better to have several CPUs inside the box, rather than in separate machines.

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.

Until which time, the OpenBSD zealots will continue to deny the issue exists or is of any importance. I see...

Re:OpenBSD is safe?

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.

Best security advice...

Just unplug your PC from the internet and wash your hands of it.. the whole thing feels holier than swiss cheese :(

Re:Best security advice...

Just unplug your PC from the internet

How would that keep you safe from DoS attacks?

Re:Best security advice...

Why would anyone put a computer running DOS on the internet in the first place?

He plans to show the exploit this Thursday!

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.

Re:He plans to show the exploit this Thursday!

Maybe the speed at which TCP was written is the problem. If they re-wrote it, I hope they did a slow re-write, because we will need the patches.

Really, I think the problem is that the flaw affected /some routers/ whose implementation of the TCP stack was flawed. That is what I gathered, anyway. If this is so, they just need to find non-flawed software.

Re:He plans to show the exploit this Thursday!

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!!

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. :P

-Bill

Neither forgotten nor stupid

The relevant parts of this vulnerability are 1) that RST attacks are much, much easier than formerly thought, making them possible for your average broadband sub, and 2) that BGP in particular is highly vulnerable, given the consequences of a terminated BGP session.

A recently published I-D (here [ietf.org]) 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.

Re:Neither forgotten nor stupid

Of course, in a sanely designed backbone, ingress filtering should be in place to filter source ips from BGP peers that aren't specifically on the interface matching the peer (yes, there's multi-hop BGP, but ignoring that for the moment...).

I do realize this likely isn't the case on many networks, but perhaps this will push such sanity (and very simple) filtering to become more widespread.

Re:Neither forgotten nor stupid

> 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).

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.

Re:He plans to show the exploit this Thursday!

From what I gathered in the two links and also my knowledge of TCP/IP, it would not necessarily require a flawed implementation of the stack in order to be vulnerable to attacks of these sort. In fact, it is the routers and/or software which doesn't implement the stack according to spec which are less likely to be affected.

In the mean time, there are a few workarounds which can be put in place, such as IPSec, and options which can be changed to reduce the liklihood of an attack, such as the window size. The smaller it is, the harder it is to guess a sequence number in the range quickly.

Not flawed, just unimaginative.

The problem isn't TCP stacks that are flawed because they don't implement TCP properly. It's TCP stacks that failed to imagine some of the creative ways to attack them. Sequence number guessing has been around for a while (see papers by Bellovin and others), but apparently the guy has figured a somewhat more efficient way to guess them on some popular platforms, apparently including Cisco routers.

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 forgin