netdev - Re: [PATCH v2 net] tcp: make challenge acks less predictable

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPzkZjwS9Kabtg0g==QrTUmyR0PUfy8C76XueanNivYSDLZZGg@mail.gmail.com>
Date:	Sun, 10 Jul 2016 11:28:10 -0700
From:	Yue Cao <ycao009@....edu>
To:	unlisted-recipients:; (no To-header on input)
Cc:	netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH v2 net] tcp: make challenge acks less predictable

This second patch does make our attack much harder but it's still
possible to do such off-path attack with enough network bandwidth.
Here is our modified attack for this second patch.

Modified Attack:
Main idea of our attack is to send multiple same spoofed packets in 1
second so attacker can confirm if it's a right guess or wrong guess.
In more detail, attacker sends more than 1000 (e.g. 1500) spoofed
packets for a same guessed value at beginning. After that, attacker
sends 1500 packets during the same second to determine whether
previous guess is right or wrong, by using following rules:
If attacker receives less than 500 Challenge ACKs, it's a right guess.
For a example, if 1500 spoofed packets are sent with a correct
value(right guess), all Challenge ACKs will be sent to victim client
in that second and attacker receives nothing. Otherwise, it's a wrong
guess.

Since this global rate limit always leaks some information as a
side-channel, we are wondering if eliminating it completely would be a
good idea. In fact, according to our latest test, FreeBSD and Windows
do not have any such rate limit implemented. Looking forward to your
replies.

Best,
Yue

On Sun, Jul 10, 2016 at 5:55 AM, Neal Cardwell <ncardwell@...gle.com> wrote:
>
> On Sun, Jul 10, 2016 at 4:04 AM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> >
> > From: Eric Dumazet <edumazet@...gle.com>
> >
> > Yue Cao claims that current host rate limiting of challenge ACKS
> > (RFC 5961) could leak enough information to allow a patient attacker
> > to hijack TCP sessions. He will soon provide details in an academic
> > paper.
> >
> > This patch increases the default limit from 100 to 1000, and adds
> > some randomization so that the attacker can no longer hijack
> > sessions without spending a considerable amount of probes.
> >
> > Based on initial analysis and patch from Linus.
> >
> > Note that we also have per socket rate limiting, so it is tempting
> > to remove the host limit in the future.
> >
> > v2: randomize the count of challenge acks per second, not the period.
> >
> > Fixes: 282f23c6ee34 ("tcp: implement RFC 5961 3.2")
> > Reported-by: Yue Cao <ycao009@....edu>
> > Signed-off-by: Eric Dumazet <edumazet@...gle.com>
> > Suggested-by: Linus Torvalds <torvalds@...ux-foundation.org>
> > Cc: Yuchung Cheng <ycheng@...gle.com>
> > Cc: Neal Cardwell <ncardwell@...gle.com>
>
> Acked-by: Neal Cardwell <ncardwell@...gle.com>
>
> Thanks, Eric!
>
> neal