Jump to content
Sign in to follow this  

Multiple Linux and FreeBSD DoS Vulnerabilities Found by Netflix

Recommended Posts

Posted (edited)

A denial of service flaw found in the way recent Linux and FreeBSD kernels handle TCP networking can be exploited by remote attackers to trigger a kernel panic in vulnerable systems.




In all, Netflix Information Security's Jonathan Looney found three vulnerabilities, two related to "the minimum segment size (MSS) and TCP Selective Acknowledgement (SACK) capabilities," and one related only to MSS, with the most serious one named SACK Panic being the one that can cause affected systems to panic and reboot.


As per Red Hat, the issues which impact the kernel's TCP processing subsystem are tracked via multiple CVEs, with CVE-2019-11477 SACK Panic having been assigned an important severity with a 7.5 CVSS3 base score, while CVE-2019-11478 and CVE-2019-11479 are considered to be moderate severity vulnerabilities.


Patches are already available as detailed in Netflix's NFLX-2019-001 security advisory, with mitigation measures also being available for machines where patching is not an immediate or easy option.

The SACK Panic security flaw

The SACK Panic vulnerability (DebianRed Hat, Ubuntu, SuseAWS) impacts Linux kernels 2.6.29 and later, and it can be exploited by "sending a crafted sequence of SACK segments on a TCP connection with small value of TCP MSS" which will trigger an integer overflow.


To fix the issue, "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," says Netflix Information Security's advisory.


To mitigate the issue, users and administrator can completely disable SACK processing on the system or block connections with a low MSS using the filters provided by Netflix Information Security HERE — the second mitigation measure will only be effective when TCP probing is also disabled.

More denial of service vulnerabilies

The other two vulnerabilities impact all Linux versions, with CVE-2019-11478 being exploitable by sending "a crafted sequence of SACKs which will fragment the TCP retransmission queue," while CVE-2019-11479 allows attackers to trigger a DoS state by sending "crafted packets with low MSS values to trigger excessive resource consumption."


Linux and FreeBSD admins and users can fix the first one can by applying PATCH_net_2_4.patch, and the second one with the PATCH_net_3_4.patch and PATCH_net_4_4.patch security patches.


As workarounds, both CVE-2019-11478 and CVE-2019-11479 can be mitigated by blocking remote network connections with a low MSS with Netflix Information Security-supplied filters available HERE — applying the filters might subsequently break low MMS legitimate connections.


"The extent of impact is understood to be limited to denial of service at this time. No privilege escalation or information leak is currently suspected," says Red Hat.


"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," also notes Netflix Information Security in its advisory.



Edited by steven36

Share this post

Link to post
Share on other sites

I'm doing a :shit: load of updates right now  that fixes this they already on  Ubuntu auto updates here . excuse me while i reboot  .:tooth:

Share this post

Link to post
Share on other sites

Sad SACK: Linux PCs, servers, gadgets can be crashed by 'Ping of Death' network packets



Ran-SACK'd, you've been SACK'd, waxed back, SACK and cracked ... The list goes on


Don't let miscreants play hacky-SACK with your gear. Apply these mitigations, patches now if you can


It is possible to crash network-facing Linux servers, PCs, smartphones and tablets, and gadgets, or slow down their network connections, by sending them a series of maliciously crafted packets. It is also possible to hamper FreeBSD machines with the same attack.


Given that Linux powers an incredible amount of stuff these days, anything from network or internet-connected TVs, routers, thermostats, light switches, CCTV cameras, and robot vacuum cleaners, to servers, PCs, Android and ChromeOS devices, smart fridges, dialysis machines, car infotainment systems, tractors, construction equipment, and uranium centrifuges, and so on, can be potentially brought to a halt by miscreants if vulnerable.


Strangers can ping some data to your device over the internet or network, and potentially crash it, in other words. Not great, not terrible; it's a rather big annoyance that could disrupt netizens if script kiddies start firing off waves of exploits.


Patches and mitigations are available, and can be applied by hand if needed, or you can wait for a security fix to be pushed or offered to your at-risk device. A key workaround is to set /proc/sys/net/ipv4/tcp_sack to 0.


At the heart of the drama is a programming flaw dubbed SACK Panic aka CVE-2019-11477: this bug can be exploited to remotely crash systems powered by Linux kernel version 2.6.29 or higher, which was released 10 years ago.


There are three other related holes: SACK Slowness, aka CVE-2019-11478, which affects Linux kernels pre-4.15, and all versions to a degree; SACK Slowness, aka CVE-2019-5599, which affects FreeBSD 12 using the RACK TCP stack; and Excess Resource Consumption Due to Low MSS Values, aka CVE-2019-11479, which affects all Linux kernel versions.


They were discovered and reported by Netflix security's Jonathan Looney, and described in an advisory issued here in the past couple of hours.


They basically revolve around an enabled-by-default feature in Linux called TCP SACK. Designed to speed up the transfer of data between computers, SACK (or Selective ACKnowledgement) allows a receiving machine to more precisely tell the sender how much data it has received and what needs to be resent. Ideally this means less data needs to be re-transmitted, and both machines can therefore shift files and other information between themselves faster. Some admins disable the feature for various reasons, one being that it is not terribly well implemented by some operating systems.


With CVE-2019-11477, a string of TCP SACK responses will cause the Linux kernel to unexpectedly hit an internal data structure limit, triggering a fatal panic. The others affecting Linux will force the system to consume resources, thus slowing it down, as Red Hat explained in its technical summary today.


Additionally, CVE-2019-5599 is a bug in the way FreeBSD handles SACK responses: it is possible to fragment an internal data structure that tracks SACKs, causing the kernel to walk long linked-lists, slowing down the system.


Thus far, Red Hat, Amazon Web Services, SUSE, and Grsecurity have all posted advisories or announced plans to soon post fixes for the flaws, with other vendors certain to follow suit in the coming hours and days.


Disabling SACK, for what it's worth, is a worthwhile workaround for now, but bear in mind it may impact your network throughput.



Share this post

Link to post
Share on other sites

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





Netflix discovers multiple 'critical' security flaws in the Linux and FreeBSD kernels' TCP stack that could lead to server outages.


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.



Share this post

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Create New...