netdev - Re: Quick Blind TCP Connection Spoofing with SYN Cookies

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]

Date:	Fri, 16 Aug 2013 11:21:47 +0200
From:	Florian Westphal <fw@...len.de>
To:	Jiri Bohac <jbohac@...e.cz>
Cc:	Jakob Lell <jakob@...oblell.com>, netdev@...r.kernel.org,
	davem@...emloft.net
Subject: Re: Quick Blind TCP Connection Spoofing with SYN Cookies

Jiri Bohac <jbohac@...e.cz> wrote:
> > The simplification of TCP Connection Spoofing described here is an
> > inherent problem of TCP SYN Cookies and so there won't be a simple
> > patch which just solves the issue and makes the Spoofing Attack as
> > hard as it is without SYN Cookies. It is only possible to gradually
> > increase the required effort for successfully spoofing a connection
> > e.g. by only accepting the last two instead of four counter values
> > (which will lead to a 60-120s 
> 
> If the counter is slowed down 4 times, accepting only two
> values should result in similar behaviour as we have today.
> 
> Can anyone think of a reason this should not be done?

I was also working on patches that mitigate this (not ready yet),
lets compare notes.

There are two problems.

1) current scheme is dangerous with HZ=1000 on 32
   bit platforms due to jiffies overflow, it needs to be fixed.

Else, cookies can be re-used exactly after 49 day period.

I did straighforward replacement first to not change current timer:

Use getnstimeofday(), take "second" value, shift result by 6 (64-second
granular timer).

If you have time to work on it, I would appreciate if you could take
care of this.

> Additionally, I believe we should reduce the number of possible MSS
> values. I think 3 values should be enough - not supporting jumbo
> frames and wasting a few bytes on sub-optimal MSS around 1400
> bytes should be acceptable when a system is under a DoS attack.

Agreed.  I had a (untested patch) that just kicks out the unlikely
values.  I used 536, 1200, 1440, 1460 for ipv4, and 536, 1220, 1460,
8940 for ipv6.  I think this would be sufficient to keep decent
connectivity for legitimate clients.

We could add an alternate fallback table with more exotic values
and use a bit in the tcp timestamp to indicate use of fallback table
however since that only workswhen ts are used I would not do this unless
there is evidence that this is useful.

As for the cookie lifetime: I agree it should be reduced, allowing
delta for more than one minute seems way too long given that we never
retransmit lost syn/ack.

A conservative change would be to reject delta <= 2, with 64 second
timer.

Cheers,
Florian
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html