netdev - Re: [PATCH] Fix corrupt TCP packets when options space overflows with MD5SIG enabled (v2)

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: <20080618023446.aba6516c.billfink@mindspring.com>
Date:	Wed, 18 Jun 2008 02:34:46 -0400
From:	Bill Fink <billfink@...dspring.com>
To:	"Adam Langley" <agl@...erialviolet.org>
Cc:	"David Miller" <davem@...emloft.net>, netdev@...r.kernel.org
Subject: Re: [PATCH] Fix corrupt TCP packets when options space overflows
 with MD5SIG enabled (v2)

On Tue, 17 Jun 2008, Adam Langley wrote:

> On Tue, Jun 17, 2008 at 5:07 PM, David Miller <davem@...emloft.net> wrote:
> > The problematic case is when all 3 of tstamps, wscale, and md5 are
> > enabled.  To be honest, tstamps are the least valuable of the 3.  The
> > only way to accurately fill in gaps is to have at least some SACK
> > information, it is much harder to guestimate than RTTs.
> 
> So, have a population of Linux hosts out there which will send corrupt
> packets when MD5+SACK is enabled. So we want to fix that problem all
> at once, hopefully.
> 
> How's this:
> 
> If we receive a SYN packet with MD5 + SACK + TS was assume that it's
> from an older kernel and reply with MD5 + TS. Not including SACK means
> that it won't send us corrupt packets and since we couldn't previously
> do SACK with these packets anyway, we're not loosing anything.
> 
> However, by default we send MD5 + SACK. If we are talking to an old
> kernel, that means that they are sending corrupt packets if they have
> > 2 SACK blocks (the current logic limits them to 4 I believe).
> Hopefully this is pretty rare (and, again, better than we are
> currently doing). It also means that we have MD5 + SACK between new
> hosts, which is optimal.

I am not particularly familiar with the TCP MD5 option, but in googling
around I found the following at the end of Section 2.2 Transmission,
of RFC 4808, "TCP-MD5 Key Change", dated March 2007:

    "Note that there is an ambiguity when an acknowledgment is received
    for a segment transmitted with two different keys.  The TCP Timestamp
    option [RFC1323] can be used for disambiguation."

This would seem to imply, that at least in some scenarios, it would be
advisable to have TS enabled in conjunction with MD5.

						-Bill
--
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