Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
This discussion has been archived. No new comments can be posted.

Severe TCP Vulnerability More

Severe TCP Vulnerability

Comments Filter:
  • I've been researching this off-and-on this afternoon. As I understand it, it's the same TCP RST exploit that's been known for upwards of six years now. The fix, which is also well-known, is in IOS 11.0.2 or something like that.
    • I've been researching this off-and-on this afternoon. As I understand it, it's the same TCP RST exploit that's been known for upwards of six years now. The fix, which is also well-known, is in IOS 11.0.2 or something like that.

      It's close to the long-known hole of sending an RST packet with the correct 4-tuple (local+remote port+IP) and the correct sequence number, but observes that the sequence number need only lie within the current congestion window. Since in most cases the remote port number and IP add

      • This sounds similar to the method used to detect machines behind a NAT. Or am I getting my TCP/IP info mixed up?

        jason
        • This sounds similar to the method used to detect machines behind a NAT. Or am I getting my TCP/IP info mixed up?

          It's related, yes; that approach depended on looking at the ISNs used, and recognizing a pattern thus going "ooh, that'll be a WinNT box then". Fortunately - as somebody pointed out in the Slashdot discussion on that article - an OpenBSD NAT box already has the ability to substitute its own (truly random - no pattern to recognize) ISNs. (ISTR something similar regarding fragment numbering, but c

    • The discoverer of the flaw thinks all the reports are overblown as well: http://www.theinquirer.net/?article=15460 [theinquirer.net].

Slashdot Top Deals

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (5) All right, who's the wiseguy who stuck this trigraph stuff in here?

Close