From: Zhiyun Qian <zhiyunq@umich.edu>
To: Eric Dumazet <erdnetdev@gmail.com>
Cc: netdev@vger.kernel.org
Subject: Re: TCP sequence number inference attack on Linux
Date: Fri, 21 Dec 2012 18:52:22 -0500 [thread overview]
Message-ID: <CALvgte-tpvyBF608MahqLc_JFZNzg2q1FpsUY72fDDicbdsBWA@mail.gmail.com> (raw)
In-Reply-To: <1356129948.21834.8002.camel@edumazet-glaptop>
On Fri, Dec 21, 2012 at 5:45 PM, Eric Dumazet <erdnetdev@gmail.com> wrote:
> On Fri, 2012-12-21 at 14:49 -0500, Zhiyun Qian wrote:
>
>> If I am not mistaken, line 6142 in kernel v3.7.1 corresponds to
>> tcp_rcv_state_process(). According to the comments, "This function
>> implements the receiving procedure of RFC 793 for all states except
>> ESTABLISHED and TIME_WAIT." Are you referring to a different kernel
>> version?
>
> You are not mistaken, it seems code is too permissive.
>
> We should reject a frame without ACK flag while in ESTABLISHED state.
>
> Thats explicitly stated in RFC 973.
>
> Then we should make all possible safety checks before even sending a
> frame or changing socket variables.
I completely agree!
>
> (For instance the tests done in tcp_ack() should be done before calling
> tcp_validate_incoming())
>
It seems that it is not straightforward to simply move tcp_ack()
before tcp_validate_incoming() as tcp_ack() currently assumes the tcp
sequence number is already validated and it may adjust certain states
purely depending on the ACK number. I guess the solution is to extract
all safety checks out and put at the very beginning. The rest of the
code in tcp_validate_incoming() and tcp_ack() may still need to
perform the redundant checks since if some state changes are dependent
on the sequence number or ACK number (e.g., window update).
I'm willing to help on this. Perhaps I can draft an initial patch and
you can help take a look before I submit it?
> John Dykstra in commit 96e0bf4b5193d0 (tcp: Discard segments that ack
> data not yet sent) did a step into right direction, but missed this.
>
> Current code assumes the incoming frame is mostly legitimate.
>
> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> index a136925..2ea4937 100644
> --- a/net/ipv4/tcp_input.c
> +++ b/net/ipv4/tcp_input.c
> @@ -5551,7 +5551,7 @@ slow_path:
> return 0;
>
> step5:
> - if (th->ack && tcp_ack(sk, skb, FLAG_SLOWPATH) < 0)
> + if (!th->ack || tcp_ack(sk, skb, FLAG_SLOWPATH) < 0)
> goto discard;
>
> /* ts_recent update must be made after we are sure that the packet
>
>
Neat change. This should enforce the ACK flag and ACK number check for
every packet received in established state.
next prev parent reply other threads:[~2012-12-21 23:52 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-21 17:58 TCP sequence number inference attack on Linux Zhiyun Qian
2012-12-21 18:31 ` Eric Dumazet
2012-12-21 18:52 ` Eric Dumazet
2012-12-21 19:13 ` Zhiyun Qian
2012-12-21 19:30 ` Eric Dumazet
2012-12-22 2:13 ` Hannes Frederic Sowa
2012-12-21 19:10 ` Zhiyun Qian
2012-12-21 19:27 ` Eric Dumazet
2012-12-21 19:49 ` Zhiyun Qian
2012-12-21 22:45 ` Eric Dumazet
2012-12-21 23:52 ` Zhiyun Qian [this message]
2012-12-22 0:01 ` Eric Dumazet
2012-12-22 0:04 ` Eric Dumazet
2012-12-22 0:08 ` Zhiyun Qian
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALvgte-tpvyBF608MahqLc_JFZNzg2q1FpsUY72fDDicbdsBWA@mail.gmail.com \
--to=zhiyunq@umich.edu \
--cc=erdnetdev@gmail.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).