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: <1468224173.30694.72.camel@edumazet-glaptop3.roam.corp.google.com>
Date:	Mon, 11 Jul 2016 10:02:53 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Yue Cao <ycao009@....edu>
Cc:	netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH v2 net] tcp: make challenge acks less predictable

On Sun, 2016-07-10 at 11:28 -0700, Yue Cao wrote:
> 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.

Are you sure Windows is implementing RFC 5961 ? Linux got in in 3.6.

We do want RFC 5961, compared to the small nuisance of the attack you
describe.

Nuisance of having a way for hackers to send a RST packet after
consuming thousands of probe packets is nothing, compared to the
nuisance of ACK storms we had before rate limiting was added in 3.6 (and
refined in 4.0). This was a serious problem for real servers, because of
buggy firewalls and appliances.

You probably know that if someone worries about TCP flows being
compromised, it should use SSL, so that traffic injection is less likely
to happen.

Most TCP flows in the Internet are short lived (less than 1 minute).

Having to establish about 500 flows to the victim is already a
challenge, since the victim would already be in trouble if it was
allowing so many idle flows.

So the 'solution' would be to backport
f2b2c582e82429270d5818fbabe653f4359d7024
("tcp: mitigate ACK loops for connections as tcp_sock")

Then apply the v2 patch so that the limit is randomized.

Then set the default limit to 2^31