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 <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>