Netflix to Linux users: Patch SACK Panic kernel bug now to stop remote attacks

June 18, 2019 TH Author

Organizations running large fleets of production Linux computers are being urged to apply new patches to stop remote attackers from crashing the machines. Three flaws affect how the Linux kernel handles TCP networking and one affects the FreeBSD TCP stack.

The most serious of the four flaws, CVE-2019-11477, is called SACK Panic, referring to the Linux kernel’s TCP Selective Acknowledgement (SACK) capabilities.

Remote attackers can exploit this flaw to trigger a kernel ‘panic’ that could crash a machine, leading to a denial of service. This affects Linux kernel versions from 2.6.29 and above.

Netflix detailed the bugs in an advisory posted on GitHub and has collectively rated them as critical-severity flaws. However, RedHat individually rates SACK Panic as having an ‘important’ severity, while the remaining bugs are considered ‘moderate’.

But Netflix’s critical rating would make sense if remote attackers could down the video-streaming giant’s Linux machines, which are likely hosted on Amazon Web Services (AWS) infrastructure.

On that note, AWS has released updates for the three Linux bugs, which affected AWS Elastic Beanstalk, Amazon Linux, Linux-based EC2 instances, Amazon Linux WorkSpaces, and Amazon’s Kubernetes container service.

Some services, such as Amazon ElastiCache are not vulnerable if left in default settings, but could be if customers have changed a configuration.

The other bugs include CVE-2019-11478 or SACK Slowness, which affects Linux 4.15 and below, CVE-2019-5599, another SACK Slowness bug that affects FreeBSD 12, and CVE-2019-11479, which causes excess resource consumption.

The three Linux flaws are related and affect how the kernel handles TCP SACK packets with low Maximum Segment Size (MSS). RedHat notes in its advisory that the impact is limited to denial of service “at this time” and that it can’t be used for privilege escalation of leaking information.

SACK is a mechanism used to improve network inefficiencies caused by TCP packet loss between sender and receiver.

The engineers who drew up SACK in a IETF- standard explain: “TCP may experience poor performance when multiple packets are lost from one window of data. With the limited information available from cumulative acknowledgments, a TCP sender can only learn about a single lost packet per round trip time. An aggressive sender could choose to retransmit packets early, but such retransmitted segments may have already been successfully received.

“A Selective Acknowledgment (SACK) mechanism, combined with a selective repeat retransmission policy, can help to overcome these limitations. The receiving TCP sends back SACK packets to the sender informing the sender of data that has been received. The sender can then retransmit only the missing data segments.”

The crash can happen due to a data structure used in Linux TCP implementations called Socket Buffer (SKB), which is capable of holding up to 17 fragments of packet data, according to RedHat.

Once that limit is reached, the result can be a kernel panic issue. The other factor is MSS, or the maximum size parameter, which specifies the total amount of data contained in a reconstructed TCP segment.

“A remote user can trigger this issue by setting the Maximum Segment Size (MSS) of a TCP connection to its lowest limit of 48 bytes and sending a sequence of specially crafted SACK packets. Lowest MSS leaves merely eight bytes of data per segment, thus increasing the number of TCP segments required to send all data,” explains RedHat.

More on Linux security