Bugtraq mailing list archives
Re: Recent troubles
From: mouse () Collatz McRCIM McGill EDU (der Mouse)
Date: Tue, 24 Jan 1995 20:52:57 -0500
Someone replied to my
If I had source, I'd probably corrupt tcp_iss on not only received packets but also [...].
with
You should read RFC 793 (if you haven't).
This was all; there was no indication _what_ in RFC793 was felt relevant. (RFC793 is the TCP spec.) I assume the section being talked about is the following part of 3.3; this is a serious enough point that I think it's worth sending this to the whole list, especially since I didn't mention this with the code I posted. +---------------- | Initial Sequence Number Selection | | The protocol places no restriction on a particular connection being | used over and over again. A connection is defined by a pair of | sockets. New instances of a connection will be referred to as | incarnations of the connection. The problem that arises from this is | -- "how does the TCP identify duplicate segments from previous | incarnations of the connection?" This problem becomes apparent if | the connection is being opened and closed in quick succession, or if | the connection breaks with loss of memory and is then reestablished. | | To avoid confusion we must prevent segments from one incarnation of a | connection from being used while the same sequence numbers may still | be present in the network from an earlier incarnation. We want to | assure this, even if a TCP crashes and loses all knowledge of the | sequence numbers it has been using. When new connections are | created, an initial sequence number (ISN) generator is employed which | selects a new 32 bit ISN. The generator is bound to a (possibly | fictitious) 32 bit clock whose low order bit is incremented roughly | every 4 microseconds. Thus, the ISN cycles approximately every 4.55 | hours. Since we assume that segments will stay in the network no | more than the Maximum Segment Lifetime (MSL) and that the MSL is less | than 4.55 hours we can reasonably assume that ISN's will be unique. +---------------- Yes, the tactic I described (and implemented) for generating harder-to-guess ISNs violates this spec. Like any method that generates "random" ISNs, it runs the risk that old segments may be mistaken for data on newly-established connections. Several factors combine to make me ignore this risk. First is that, assuming the method does generate reasonably random ISNs, it's unlikely. For a 4K maximum window size, it would require a one-in-a-million coincidence (4G/4K), and even then it would have to hit all the unlikely items below. (For fat-pipe TCP, the chance is higher; for a half-meg window, for example, it's more like one in 8192.) Second is that it requires an unlikely coincidence for it to be possible at all: one host must send out a segment, crash, reboot, reset the old connection, establish a new one, and only then have the old segment come wandering in from having taken the long way around. I don't think I've ever seen a Sun (my code was for Suns, remember) that can reboot fast enough for the old segment to still be within its TTL. I've never seen trip-time variance high enough to provoke this, either, even if machines could reboot fast enough. Third is that the new connection must use exactly the same port numbers as the old. Unless the other end of the connection crashes too, this is extremely unlikely because it will have a TIME_WAIT socket sitting around preventing this. Fourth is the quiet time on TCP reboot, specifically for old segments to run out of TTL. If and when machines reboot fast enough for this to be a problem, their TCPs need to be taught about this anyway, and that should take care of it. Thus, I'll take the resistance to known attacks over the small risk that two simultaneous host crashes, a very peculiar routing glitch, extremely accelerated reboots, and a fluke somewhere between one in 8192 and one in 2^20 all conflue to corrupt a connection. You may choose differently. You're welcome to. Unless of course you can suggest some better solution, something I can implement in (say) less than 48 hours (my defense was done the same afternoon I did the defense against LKMs and /dev/*mem). I agree that TCP needs to be redesigned...but that's not much help when machines are being attacked _today_. I'll be glad to talk redesign, once I have some insulation against existing crackers. der Mouse mouse () collatz mcrcim mcgill edu
Current thread:
- Re: Recent troubles der Mouse (Jan 24)
- Re: Recent troubles Darren Reed (Jan 24)
- preventing sequence number guessing David A. Wagner (Jan 24)
- Re: preventing sequence number guessing Darren Reed (Jan 24)
- accpet(3n) under SOlaris 2.4 Jas (Jan 25)
- Re: accpet(3n) under SOlaris 2.4 Casper Dik (Jan 25)
- Re: preventing sequence number guessing Timothy Newsham (Jan 25)
- IP Spoofing and Vendors' attitude Christopher Klaus (May 12)
- Re: IP Spoofing and Vendors' attitude Oliver Friedrichs (Jan 25)
- Re: IP Spoofing and Vendors' attitude Mark (Jan 26)
- Re: preventing sequence number guessing David A. Wagner (Jan 25)