Vendor TCP oops-es (was Re: TCP/BGP vulnerability)

[Todd Vierling <tv () duh org>]

On Wed, 21 Apr 2004, Pete Kruckenberg wrote:

: Interesting that Cisco uses random port selection with
: SNMP (http://www.cisco.com/warp/public/707/cisco-sa-20040420-snmp.shtml,
: see the Detail selection) but not with TCP.
:
: Too bad that TCP ports aren't randomized even with the
: "fixed" IOS versions. Would seem that as long as you're
: implementing security features like TCP RST confirmation,
: might as well implement randomized source ports.

Yes.  For the BSD world -- modulo some related but not quite identical
issues[*] -- the subject of this "Advisory" has not been a problem for a
very long time.

It's NOT a 2^[15..17] problem as described by the "Advisory".  In a properly
implemented OS, it's a 2^[29..33] problem.  To wit:

Let's say the window size is ridiculously wide (2^18, 262144), making a
match against the rest of the sequence bits have probability one in 2^14.
That's obviously something pretty easy to hit with a shotgun blast, even
over DSL.  Hell, dialups could hit it.  ISTR killing folks' IRC sessions in
the early '90s with precisely this kind of spoof over a dialup -- but then,
I had access to the system where the IRC client was running, and could
"netstat" to find the source and destination IP and port.

For the case of something more well confined to admins only, say BGP, the
source port is NOT a known value to the attacker.  Multiply probability by
2^16.  Or, to be conservative, let's say that 3/4 of the ports aren't used
for random allocation, so instead multiply by 2^14:  it's now a 2^28
problem.

We do know that the dest port is 173, but there's the possibility that one
or the other peer initiated the valid session.  Add one bit.  Now 2^29.
And that's a worst-case scenario.  Better configuration could bring this up
to 2^33 easily.

The only assumption in this description is that the source port and initial
sequence number for those BGP sessions is [pseudo]randomly allocated.  So
the only way that the "Advisory" in question is anything like a security
risk is in the vendor's implementation of TCP source port allocation.

Now, don't get me wrong; this "Advisory" is bringing about some much needed
sanity checking of various TCP stacks.  I just believe it is pointing the
finger the wrong way (and NANOG'ers are eating it up like sweet potato pie).

[*] I must admit one thing, for instance:  This "Advisory" was a problem
for NetBSD, but not because its port allocation scheme was crappy.  It so
happened that NetBSD wasn't properly validating the sequence number to be
within the window.  "Oops."  It's just been fixed as I write this.

-- 
-- Todd Vierling <tv () duh org> <tv () pobox com>