Allele Security Alert
ASA-2019-00366
Identifier(s)
ASA-2019-00366, CVE-2019-11478, NFLX-2019-001
Title
Excessive resource consumption while processing SACK blocks allows remote denial of service
Vendor(s)
Linux foundation
Product(s)
Linux kernel
Affected version(s)
All Linux kernel versions
Fixed version(s)
Linux kernel stable version 4.4.182
Linux kernel stable version 4.9.182
Linux kernel stable version 4.14.127
Linux kernel stable version 4.19.52
Linux kernel stable version 5.1.11
Linux kernel with the following commit applied:
tcp: tcp_fragment() should apply sane memory limits
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=f070ef2ac66716357066b683fb0baf55f8191a2e
Proof of concept
Unknown
Description
An excessive resource consumption flaw was found in the way the Linux kernel’s networking subsystem processed TCP Selective Acknowledgment (SACK) segments. While processing SACK segments, the Linux kernel’s socket buffer (SKB) data structure becomes fragmented, which leads to increased resource utilization to traverse and process these fragments as further SACK segments are received on the same TCP connection. A remote attacker could use this flaw to cause a denial of service (DoS) by sending a crafted sequence of SACK segments on a TCP connection.
Technical details
Jonathan Looney reported that a malicious peer can force a sender to fragment its retransmit queue into tiny skbs, inflating memory usage and/or overflow 32bit counters.
TCP allows an application to queue up to sk_sndbuf bytes, so we need to give some allowance for non malicious splitting of retransmit queue.
A new SNMP counter is added to monitor how many times TCP did not allow to split an skb if the allowance was exceeded.
Note that this counter might increase in the case applications use SO_SNDBUF socket option to lower sk_sndbuf.
CVE-2019-11478 : tcp_fragment, prevent fragmenting a packet when the socket is already using more than half the allowed space
Workaround
1 – Block connections with a low MSS using filters. 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).
2 – Disable SACK processing (/proc/sys/net/ipv4/tcp_sack
set to 0).
Credits
Jonathan Looney (Netflix Information Security)
Reference(s)
Linux and FreeBSD Kernel: Multiple TCP-based remote denial of service vulnerabilities
https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-001.md
Linux and FreeBSD Kernel: Multiple TCP-based remote denial of
service issues
https://www.openwall.com/lists/oss-security/2019/06/17/5
Bug 1719128 (CVE-2019-11478) – CVE-2019-11478 Kernel: tcp: excessive resource consumption while processing SACK blocks allows remote denial of service
https://bugzilla.redhat.com/show_bug.cgi?id=1719128
SACK Panic and Other TCP Denial of Service Issues
https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SACKPanic
CVE-2019-11477, CVE-2019-11478, CVE-2019-11479
https://blog.mikrotik.com/security/cve-2019-11477-cve-2019-11478-cve-2019-11479.html
tcp: tcp_fragment() should apply sane memory limits
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=f070ef2ac66716357066b683fb0baf55f8191a2e
ASA-2019-00407 – VMware: Selective Acknowledgement (SACK) Excess Resource Usage
https://allelesecurity.com/asa-2019-00407/
Advisory: TCP SACK PANIC kernel vulnerability
https://community.sophos.com/kb/en-us/134237
CVE-2019-11478
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11478
CVE-2019-11478
https://nvd.nist.gov/vuln/detail/CVE-2019-11478
CVE-2019-11478 - Red Hat Customer Portal
https://access.redhat.com/security/cve/CVE-2019-11478
CVE-2019-11478 | SUSE
https://www.suse.com/security/cve/CVE-2019-11478
https://people.canonical.com/~ubuntu-security/cve/CVE-2019-11478.html
CVE-2019-11478
https://security-tracker.debian.org/tracker/CVE-2019-11478
If there is any error in this alert or you wish a comprehensive analysis, let us know.
Last modified: July 23, 2019