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-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20080617.170718.260234361.davem@davemloft.net>
Date:	Tue, 17 Jun 2008 17:07:18 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	agl@...erialviolet.org
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH] Fix corrupt TCP packets when options space overflows
 with MD5SIG enabled (v2)

From: "Adam Langley" <agl@...erialviolet.org>
Date: Tue, 3 Jun 2008 14:52:00 -0700

> When MD5 signatures are turned on we can end up with syntactically invalid
> packets with a header length < 20 bytes. This is because tcp_header_size
> overflows with 12 bytes of timestamp, 20 bytes of signature and > 8 bytes of
> SACK option.
> 
> Since we can't fit any SACK blocks in the final 8 bytes of options space, and
> the MD5 signature is more important, we disable including SACK, or even
> advertising it, when MD5 is enabled.
> 
> Signed-off-by: Adam Langley <agl@...erialviolet.org>

If this is the case, I think we need to simply prioritize at option
negotiation time and leave it at that.  The data paths don't need
to be modified.

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, actually, we'd need to add logic to limit the amount of SACK
blocks we report when MD5 is present, in the output packet building
code.
--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ