|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Massive stupidity (Was: Re: TCP vulnerability)
On Tue, Apr 20, 2004 at 10:36:48AM -0700, Grant A. Kirkwood wrote: > > Since no one's mentioned it yet, apparently there was a change in plans. > It was just released a day early. > > http://story.news.yahoo.com/news?tmpl=story&cid=528&e=1&u=/ap/20040420/ap_on_hi_te/internet_threat > > And the official one: > > http://www.uniras.gov.uk/vuls/2004/236929/index.htm Allow me to quote some of my favorite parts for a second: > Although denial of service using crafted TCP packets is a well known > weakness of TCP, until recently it was believed that a successful denial > of service attack was not achievable in practice. The reason for this is > that the receiving TCP implementation checks the sequence number of the > RST or SYN packet, which is a 32 bit number, giving a probability of > 1/232 of guessing the sequence number correctly (assuming a random > distribution). > > The discoverer of the practicability of the RST attack was Paul A. > Watson, who describes his research in his paper �Slipping In The Windo: > TCP Reset Attacks, presented at the CanSecWest 2004 conference. He > noticed that the probability of guessing an acceptable sequence number > is much higher than 1/232 because the receiving TCP implementation will > accept any sequence number in a certain range (or �window�) of the > expected sequence number. The window makes TCP reset attacks > practicable. Sooooooooooooooooooooooooooooooooooo... This begs the question... Exactly how much research DID it take to read RFC793 page 37, which clearly states: Reset Processing In all states except SYN-SENT, all reset (RST) segments are validated by checking their SEQ-fields. A reset is valid if its sequence number is in the window. In the SYN-SENT state (a RST received in response to an initial SYN), the RST is acceptable if the ACK field acknowledges the SYN. The receiver of a RST first validates it, then changes state. If the receiver was in the LISTEN state, it ignores it. If the receiver was in SYN-RECEIVED state and had previously been in the LISTEN state, then the receiver returns to the LISTEN state, otherwise the receiver aborts the connection and goes to the CLOSED state. If the receiver was in any other state, it aborts the connection and advises the user and goes to the CLOSED state. This is not rocket science, every TCP stack in existance implements this exactly this way. The fact that ANYONE ever thought it was 2^32 packets to hit upon the sequence number for a forged reset shows pure ignorance and an inability to read on their part, but the massive amount of confusion, rumor, and worry which the major router vendors (Cisco and Juniper) created by essentially rediscovering the god damn spec and then telling only their major customers about so that only rumors could filter down to the rest of the industry is absolutely pathetic. If you have a support contract and were not told about this "attack" (if you could call it that) or were blatantly misinformed as many people seem to have been, you should demand to know why you didn't receive better treatment. Bottom line, this attack is no more practical now than it was yesterday. Let's run some numbers for a second shall we. First off, as I'm sure everyone knows, BGP sessions are formed when one side establishes a tcp connection from a high numbered ephemeral port to port 179. Both sides actively attempt to connect to each other on and off through an alternating series of Connect and Active states, but eventually one side will connect to the other and only one session will survive the collision handling process. Now, let us just use Juniper as a worst case example, since they seem to have a very very restricted set of ephemeral ports for some reason or another (low 1024 high 5000, 3976 possible ports). Given the default settings of a recvsockbuf size 16384, the maximum advertised receive window will be 16384. This cuts the total sequence space to be scanned down from 2^32 to 2^32 / 2^14 = 262144 packets. Now, even though the outbound port is a simple incrementation, an outside party has no way to know what the current number is (and in the case of long lived connections it may not do them any good at all, though theoretically routers just rebooted could be more vulnerable). It is also impossible for an outside party to know which side won the collision handling. Therefore you need 262144 packets * 3976 ephemeral ports (assuming both sides are jnpr, again worst case) * 2 (to figure out who was the connecter and who was the accepter) = 2084569088 packets to exhaustively search all space on this one single Juniper to Juniper session. Now, lets just for the sake of argument say that the router is capable of actively processing 10,000 packets/sec of rst (a fairly exagerated number) and still have this be considered a tcp attack instead of a straight DoS against the routing engine. This will still take 208456 seconds, or 57.9 hours. Anyone who seriously wanted to protect against this attack could easily deploy RST rate limits against their management interfaces, rather than run around trying to set up MD5 with every peer. As a long term improvement, a random ephemeral port selection process could be used. -- Richard A Steenbergen <[email protected]> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
|