[ale] [Fwd: IETF Draft on Transmission Control Protocol securityconsiderations]

Chris Ricker kaboom at gatech.edu
Wed Apr 21 17:46:17 EDT 2004


On Wed, 21 Apr 2004, Greg wrote:

> This is on the OpenBSD list a lot also - but it is of concern to Cisco and
> their ilk.  What's broken is Cisco and their gear.  More corporate FUD,
> though since a great many place their undying trust in Cisco, I guess it is
> a threat to those that have an all Cisco network.  Also was mentioned in the
> OpenBSD posts was how Cisco's training only looked at one aspect of the
> problem and how the other aspects have come home to roost.  Funny how there
> is no mention of Cisco or others in the post - and this is what makes it
> seem like it's an "everyone in the world" issue.

I'm not sure what you've been reading there, but it sounds misleading.
Anything with a TCP stack, OpenBSD included, is susceptible to spoofed TCP
resets.

A reset, to be accepted as valid by the recipient, has to at a minimum have
the correct source and destination ports and source and destination IP
addresses. If I'm attacking you, getting those will vary in difficulty based
on what protocol I'm attacking and the TCP implementations involved.... All 
that was very widely known.

A spoofed reset also has to have the correct sequence number to be accepted
by the recipient. The major news (if you want to call it that) in this round
of announcements was simply to publicize the fact that the sequence number
doesn't have to be the expected_next_sequence_number (ie, a 1/2^32 chance of
blind spoofing), but instead just has to be any number >=
expected_next_sequence_number and <= (expected_next_sequence_number + window
size). The "vulnerability" here is that it's not a 1/2^32 chance of spoofing
the sequence number, as had sometimes been assumed, but rather a 1 / (2^32 /
window_size) chance. On OpenBSD, the default window is 16k, so you're
talking a 1 / 2^18 chance (ignoring window negotiation) once the 4-tuple has
been determined....

Now, that's not to say that there aren't things OpenBSD does which help
offset this (cvs OpenBSD randomizes ephemeral ports, for example, making
determination of the 4-tuple more difficult for some protocols), but the
basic "vulnerability"  being discussed is an inherent TCP problem. It
affects OpenBSD, Linux, Windows, anything with a TCP stack. It's not just a
Cisco problem (and in fact, Cisco is likely less vulnerable than some other
router vendors).

That's also not to say that the vulnerability is nearly as serious as CNN et
al's "the Internet is about to be publically raped, pillaged, and plundered"  
stories about it have made it seem ;-)

later,
chris



More information about the Ale mailing list