nanog mailing list archives
Vendor TCP oops-es (was Re: TCP/BGP vulnerability)
From: Todd Vierling <tv () duh org>
Date: Wed, 21 Apr 2004 15:18:19 -0400 (EDT)
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>
Current thread:
- Re: TCP/BGP vulnerability - easier than you think, (continued)
- Message not available
- Re: TCP/BGP vulnerability - easier than you think Iljitsch van Beijnum (Apr 23)
- Re: TCP/BGP vulnerability - easier than you think Leo Bicknell (Apr 23)
- Re: TCP/BGP vulnerability - easier than you think Petri Helenius (Apr 23)
- Re: TCP/BGP vulnerability - easier than you think Todd Vierling (Apr 23)
- Re: TCP/BGP vulnerability - easier than you think Priscilla Oppenheimer (Apr 26)
- Re: TCP/BGP vulnerability - easier than you think Iljitsch van Beijnum (Apr 27)
- Re: TCP/BGP vulnerability - easier than you think Priscilla Oppenheimer (Apr 27)
- Re: TCP/BGP vulnerability - easier than you think Simon Leinen (Apr 28)
- Re: TCP/BGP vulnerability - easier than you think Todd Vierling (Apr 21)
- Re: TCP/BGP vulnerability - easier than you think Pete Kruckenberg (Apr 21)
- Vendor TCP oops-es (was Re: TCP/BGP vulnerability) Todd Vierling (Apr 21)
- Re: Vendor TCP oops-es (was Re: TCP/BGP vulnerability) Iljitsch van Beijnum (Apr 21)
- Re: Massive stupidity (Was: Re: TCP vulnerability) Alexei Roudnev (Apr 22)