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

Organizations using large number of Linux computers are now urged to apply new patches to prevent themselves from remote attackers, crashing their systems. Four major flaws are being identified among whom three affect the way Linux Kernel handles TCP networking and the other affects the FreeBSD TCP stack. But the most serious of these four flaws, CVE-2019-11477, is called SACK Panic and refers to Linux Kernel's TCP Selective Ack (SACK) capabilities.

Remote hackers can launch an exploit on this flaw to trigger a kernel 'panic' which would crash a machine, leading to DoS. This is observed to affect Linux kernel versions above 2.6.29. Netflix detailed these bugs on an advisory posted in GitHub and has rated this as critical-severity flaws, while RedHat rates SACK Panic as an important severity leaving the others as moderate. Netflix -Video streaming giant is in an urge for an update to prevent its Linux machines from going down.

On this note, Amazon Web Services has released updates for three linux bugs which affected Linux-based EC2 instances, AWS Elastic Beanstalk, Amazon Linux WorkSpaces, Amazon Linux, and Amazon's Kubernetes container service. While some services as Amazon ElastiCache are not really vulnerable provided they are left in default settings, but could be vulnerable if incase customers have changed a configuration.

The other bugs include SACK Slowness or CVE-2019-11478 and affect Linux Kernels 4.15 and below, while another SACK Slowness bug CVE-2019-5599, affects FreeBSD 12, and CVE-2019-11479, causes excess resource consumption. These three Linux flaws are related to each other and affect the way kernel handles TCP SACK packets with low Maximum Segment Size (MSS). RedHat notes in its advisory that the impact of these vulnerabilities are limited to denial of service "at this time" but that it can't be used for privilege escalation for leaking of information.

SACK - 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 explained that TCP may recognize poor performance when multiple data packets get lost from one window of data. With this incomplete information available from cumulative acknowledgments, a TCP sender can only learn about a single lost packet per round trip time, while an aggressive sender could choose to resend packets early, but such resent segments may have already been successfully received.

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

This crash can be an outcome of a data structure used in Linux TCP implementations called Socket Buffer (SKB), According to RedHat this data structure is capable of holding about 17 fragments of data packets.

Once this limit is reached, the result would be a kernel panic issue. The other factor is maximum size parameter or MSS, and marks the total amount of data enclosed in a reconstructed TCP segment.

RedHat explained that,"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 MS size leaves merely eight bytes of data per segment, thus increases the number of TCP segments required to send all the data,"