netdev - Re: [PATCH 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 for Android: free password hash cracker in your pocket

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

Message-ID: <1468052160.30694.51.camel@edumazet-glaptop3.roam.corp.google.com>
Date:	Sat, 09 Jul 2016 10:16:00 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Yue Cao <ycao009@....edu>
Cc:	David Miller <davem@...emloft.net>,
	netdev <netdev@...r.kernel.org>,
	Zhiyun Qian <zhiyunq@...ucr.edu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Yuchung Cheng <ycheng@...gle.com>
Subject: Re: [PATCH net] tcp: make challenge acks less predictable

On Fri, 2016-07-08 at 17:27 -0700, Yue Cao wrote:
> Hi Eric, 
> 
> 
> Thank you for the email. After rethinking the suggested patch, our
> side-channel attack might still work.
> 
> 
> The main idea behind the patch is to change challenge_count lifetime
> from 1s to a random value in the range [0.5s, 1.5s), which creates a
> time synchronization issue at the attacker's end. 
> 
> 
> In our modified attack, 
> 1. Instead of sending several packets throughout the 1s duration,
> attacker sends fewer packets in a short period (e.g. 0.1s, or even
> shorter). It is likely that this short period will be included in one
> challenge_count lifetime at the server’s end.
> 2. If this short period covers two challenge_counts’ lifetime or some
> rare case that attacker is not sure, attacker can repeat sending same
> packets after a short period (e.g. 1.5s) to confirm it. 
> 3. These packets should include one or more spoofed packets and 1005(a
> value bigger than 1001) packets to exhaust such side channel. 
> 
> 
> In summary, if the attacker receives less than 1000 packets from the
> server, it must be a good guess. If the attacker receives more than
> 1000 packets from the server, this short period covers two
> challenge_counts’ lifetime and the attacker has to repeat sending same
> packets after a short duration. If the attacker receives exactly 1000
> packets from the server, it is most likely a wrong guess. However, the
> attacker would better repeat sending packets to confirm it since these
> 1000 packets may be sent from two continuous challenge_counts’
> lifetime(though it’s a rare case).

OK so all we need is to vary the 1000 value a bit so that attacker can
not predict it, as Linus first did.

I will send a V2, thanks a lot !