Date: Tue, 18 Jun 2019 10:33:00 -0400 From: mike tancsa <mike@sentex.net> To: "freebsd-security@freebsd.org" <freebsd-security@freebsd.org> Subject: TCP SACK (CVE-2019-5599) Message-ID: <29d6e221-e88a-f828-0e5b-ac235691ed86@sentex.net>
next in thread | raw e-mail | index | archive | help
Hi all, With respect to the bugs describe in https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-001.md *<quote> * SACK Slowness (FreeBSD 12 using the RACK TCP Stack) *Description:* It is possible to send a crafted sequence of SACKs which will fragment the RACK send map. An attacker may be able to further exploit the fragmented send map to cause an expensive linked-list walk for subsequent SACKs received for that same TCP connection. *Workaround #1:* Apply the patch split_limit.patch <https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-001/split_limit.patch> and set the |net.inet.tcp.rack.split_limit| sysctl to a reasonable value to limit the size of the SACK table. *Workaround #2:* Temporarily disable the RACK TCP stack. (Note that either workaround should be sufficient on its own. It is not necessary to apply both workarounds.) *</quote>* *How does I know if this is enabled in my default kernel on RELENG_12 ? There is some vague mention in various forums this is not the default on FreeBSD ? Can anyone shed more light as to how this does/does not impact FreeBSD ? * * * * ---Mike *
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?29d6e221-e88a-f828-0e5b-ac235691ed86>