Re: TCP sequence number inference attack on Linux
From: Eric Dumazet <hidden>
Date: 2012-12-21 19:27:34
On Fri, 2012-12-21 at 14:10 -0500, Zhiyun Qian wrote:
That's good to know. However, implementing RFC 5961 alone is not sufficient. Like I said, since DelayedAckLost counter is incremented purely upon looking at the sequence number, regardless of the ACK number. An attacker thus can still infer the sequence number based on DelayedAckLost counter without knowing the right ACK number.
The next question is how can the attacker eventually know the right ACK number in order to inject real data. It turns out that this is not hard either. First, based on the current Linux TCP stack, it accepts incoming packets without ACK flag.
I dont really think so. We must discard frame is th->ack is not set. (Step 5, line 6142)
Further, if ACK flag is not set, ACK number will not be checked at all. See code in net/ipv4/tcp_input.c, function tcp_rcv_established() 5547 if (th->ack && tcp_ack(sk, skb, FLAG_SLOWPATH) < 0) 5548 goto discard; Second, even if ACK number is always checked before accepting the payload, it is still possible to infer the ACK number much like how sequence number can be inferred. The details is described in Section 3.4 of my paper, paragraph starting with "Client-side sequence number inference". I'm looking at the latest kernel v3.7.1 right now. I believe the problem do still exist in today's Linux.
It seems you know pretty well this code, I wonder why you dont send patches to fix the bugs... Its not like it has to be buggy forever.