Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 688254 (CVE-2019-11477, CVE-2019-11478, CVE-2019-11479) - [TRACKER] SACK Panic
Summary: [TRACKER] SACK Panic
Status: RESOLVED FIXED
Alias: CVE-2019-11477, CVE-2019-11478, CVE-2019-11479
Product: Gentoo Security
Classification: Unclassified
Component: Kernel (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Kernel Security
URL: https://github.com/Netflix/security-b...
Whiteboard: A3
Keywords: Tracker
Depends on: 688256
Blocks:
  Show dependency tree
 
Reported: 2019-06-17 22:00 UTC by GLSAMaker/CVETool Bot
Modified: 2022-03-26 01:02 UTC (History)
7 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description GLSAMaker/CVETool Bot gentoo-dev 2019-06-17 22:00:31 UTC
Incoming details.
Comment 1 Thomas Deutschmann (RETIRED) gentoo-dev 2019-06-17 22:02:36 UTC
From $URL:

Overview:

Netflix has identified several TCP networking vulnerabilities in FreeBSD and Linux kernels.

The vulnerabilities specifically relate to the minimum segment size (MSS) and TCP Selective Acknowledgement (SACK) capabilities. The most serious, dubbed “SACK Panic,” allows a remotely-triggered kernel panic on recent Linux kernels.

There are patches that address most of these vulnerabilities. If patches can not be applied, certain mitigations will be effective. We recommend that affected parties enact one of those described below, based on their environment.
Details:


1: CVE-2019-11477: SACK Panic (Linux >= 2.6.29)

Description: A sequence of SACKs may be crafted such that one can trigger an integer overflow, leading to a kernel panic.

Fix: Apply the patch PATCH_net_1_4.patch. Additionally, versions of the Linux kernel up to, and including, 4.14 require a second patch PATCH_net_1a.patch.

Workaround #1: Block connections with a low MSS using one of the supplied filters. (The values in the filters are examples. You can apply a higher or lower limit, as appropriate for your environment.) Note that these filters may break legitimate connections which rely on a low MSS. Also, note that this mitigation is only effective if TCP probing is disabled (that is, the net.ipv4.tcp_mtu_probing sysctl is set to 0, which appears to be the default value for that sysctl).

Workaround #2: Disable SACK processing (/proc/sys/net/ipv4/tcp_sack set to 0).

(Note that either workaround should be sufficient on its own. It is not necessary to apply both workarounds.)


2: CVE-2019-11478: SACK Slowness (Linux < 4.15) or Excess Resource Usage (all Linux versions)

Description: It is possible to send a crafted sequence of SACKs which will fragment the TCP retransmission queue. On Linux kernels prior to 4.15, an attacker may be able to further exploit the fragmented queue to cause an expensive linked-list walk for subsequent SACKs received for that same TCP connection.

Fix: Apply the patch PATCH_net_2_4.patch

Workaround #1: Block connections with a low MSS using one of the supplied filters. (The values in the filters are examples. You can apply a higher or lower limit, as appropriate for your environment.) Note that these filters may break legitimate connections which rely on a low MSS. Also, note that this mitigation is only effective if TCP probing is disabled (that is, the net.ipv4.tcp_mtu_probing sysctl is set to 0, which appears to be the default value for that sysctl).

Workaround #2: Disable SACK processing (/proc/sys/net/ipv4/tcp_sack set to 0).

(Note that either workaround should be sufficient on its own. It is not necessary to apply both workarounds.)


3: CVE-2019-5599: 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 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.)


4: CVE-2019-11479: Excess Resource Consumption Due to Low MSS Values (all Linux versions)

Description: An attacker can force the Linux kernel to segment its responses into multiple TCP segments, each of which contains only 8 bytes of data. This drastically increases the bandwidth required to deliver the same amount of data. Further, it consumes additional resources (CPU and NIC processing power). This attack requires continued effort from the attacker and the impacts will end shortly after the attacker stops sending traffic.

Fix: Two patches PATCH_net_3_4.patch and PATCH_net_4_4.patch add a sysctl which enforces a minimum MSS, set by the net.ipv4.tcp_min_snd_mss sysctl. This lets an administrator enforce a minimum MSS appropriate for their applications.

Workaround: Block connections with a low MSS using one of the supplied filters. (The values in the filters are examples. You can apply a higher or lower limit, as appropriate for your environment.) Note that these filters may break legitimate connections which rely on a low MSS. Also, note that this mitigation is only effective if TCP probing is disabled (that is, the net.ipv4.tcp_mtu_probing sysctl is set to 0, which appears to be the default value for that sysctl).
Note:

Good system and application coding and configuration practices (limiting write buffers to the necessary level, monitoring connection memory consumption via SO_MEMINFO, and aggressively closing misbehaving connections) can help to limit the impact of attacks against these kinds of vulnerabilities.
Comment 2 Gordon Pritchard 2019-06-20 16:34:57 UTC
OK... I wonder what the SACK status is, for Gentoo?  I ask because several other distributions I maintain at work have been patched earlier this week.

Thomas - I note your "Depends on..." but when I review that, I only see a stabilization-request for newer kernels, without any mention of SACK / MSS, etc.  So it remains unclear why or how this Bug depends on that Bug.

Thanks for clarifying,
Comment 3 kfm 2019-06-22 15:57:09 UTC
These issues are addressed by the following stable and longterm releases:

5.1.11
4.19.52
4.14.127
4.9.182
4.4.182

For x86 and amd64, gentoo-sources-4.19.52 is currently keyworded as stable.
Comment 4 John Helmert III archtester Gentoo Infrastructure gentoo-dev Security 2022-03-26 01:02:14 UTC
Not sure why this was ever a tracker with only one dependency, but that one dependency has been fixed for some time.