Security concerns with TCP holding onto out-of-order packets?

Question

Consider the following...

Alice and Bob are communicating over TCP. Currently, the next expected TCP sequence number is 1000. Charlie, pretending to be Alice, sends a spoofed TCP packet to Bob with a sequence number of 1003. Bob's computer holds onto this packet thinking that it arrived out of order. Meanwhile, Alice continues sending packets to Bob, sequenced as 1000, 1001, and 1002. Now, Bob's computer processes the spoofed TCP packet thinking it is the next in sequence.

In this scenario, assuming my understanding is correct, it seems that the attacker doesn't need to exactly predict the next sequence number, but rather just needs to guess the a sequence number that is greater than or equal to the current sequence, but also close enough to the sequence number so that it doesn't expire... as surely it won't hold on to the out-of-order packet forever.

This raises the following questions...

1) Is my understanding of the scenario I described correct?

2) What determines how long an out-of-order packet should be kept, while it waits for the previously sent packets?

3) What would happen to the TCP session when Alice finally sends a packet with TCP sequence 1003, given that Charlie's spoofed packet was already processed?

Answer 1

This is limited by the TCP window size.

It's not enough to just guess any number greater than the sequence number; it must be between the sequence number and (sequence number + window size).

I don't know how much easier this makes brute forcing a sequence number in practice. "Overlapping fragments" has been the cause of some historic vulnerabilities, but I believe all modern TCP stacks have good defences.

Answer 2

How does the attacker (Charlie) see the traffic to know the sequence number? If they have the capability to monitor traffic between A&B nothing can be expected of non-secure traffic since.

In all other cases http://www.ietf.org/rfc/rfc1948.txt

Answer 3

1. The segment is hold only if @paj28 condition is true.

2. It depends on the stack reassembly timer, which could be computed according to variable parameters such as RTT.

3. If there was no reassembly timeout, it depends on the stack's reassembly policy: the segment could be replaced with the new one (e.g. Linux stack) or the first segment could be kept (e.g. Windows stack).

The attacker doesn't have to know exactly the sequence number but doesn't mean he controls data flow as reassembly is implementation dependant. He has to know which system he is sending segments to.

Ptacek and Newsham paper section 5.4 is a good explanation.