sack-panic-blog

Protect Your Hospital Against SACK Panic

One month after BlueKeep, another major operating system vulnerability has been discovered this week, this time in the Linux kernel. In its security advisory, Netflix described four vulnerabilities in the way the kernel handles TCP networking. The most severe one takes advantage of a flaw in the kernel’s TCP Selective Acknowledgement (SACK) mechanism, and an attacker can exploit it to trigger a kernel ‘panic’ that crashes the machine, hence the name “SACK Panic.”

The widespread use of Linux for IoT and IoMT devices demands immediate attention to this disclosure across healthcare security stakeholders, from device manufacturers to hospital security and clinical engineering teams to our security researchers at Medigate Labs. To make things clearer, let’s start by:

  • Clarifying the essence of the SACK Panic flaw
  • Defining the properties a device must fulfill to be affected
  • Understanding the practical remediation and mitigation processes to secure the vulnerable Linux devices.

What is SACK Panic?

TCP Selective Acknowledgement (SACK) is an option in the TCP protocol that enables a receiver endpoint in the TCP communication to acknowledge the sender which data segments have arrived, even if the received segments have not been continuous in the TCP stream (hence “Selective ACK”).

The most severe of the four vulnerabilities was found in the Linux kernel’s handling of the TCP protocol, particularly with the option called SACK panic. The SACK panic vulnerability is triggered by sending specially-crafted TCP packets with the SACK option and also by lowering the maximum segment size (MSS) for the TCP session to a minimum of 48 bytes.

Such a scenario would cause an integer overflow in the Linux kernel of the device that received the TCP SACK packets, triggering a kernel panic and causing the system to halt. As of now, the vulnerability does not seem to allow remote code execution or privilege escalation similar to the BlueKeep vulnerability.

Which devices are affected?

There are three conditions a device must satisfy to be susceptible to SACK Panic:

  1. Establishing TCP communication with a device, which is fairly straightforward.
  2. The device must run a Linux kernel versions 2.6.29 and above. Many IoT and IoMT devices run these kernel versions, including glucose meters, infusion pumps and patient monitors from various vendors.
  3. The device must have a Network Interface Card (NIC) in which a specific feature (called Segmentation Offloading) is enabled.

How can you tell which of your Linux devices are at risk?

First, you need comprehensive visibility of all connected devices down to their kernel versions to identify those running 2.6.29 and above. It can be tedious without an in-tact inventory or the right tools to extract this information from your network, but it’s essential to identify all vulnerable assets to enable informed, comprehensive remediation and mitigation processes. The Medigate platform automatically displays all devices running the susceptible kernel versions.

Unfortunately, it is much harder to determine what devices have NICs that have the essential feature enabled without further examining their operating systems and configurations, which is in most cases very hard to do on IoT and IoMT devices, certainly not without manufacturer collaboration. Mapping out all vulnerable assets can greatly assist in prioritizing assets for further inspection.

Taking action to protect your IoT and IoMT devices

The most direct remedy to SACK Panic is patching the Linux kernel, which requires collaborating with the device manufacturers. Other solutions include disabling the SACK mechanism on the device or re-configuring it to set a larger TCP minimum segment size parameter rather than then kernel default of 48 which disarms the potential exploits, but these also require executing code directly on the device’s operating system.

Such changes to the TCP protocol parameters must be tested rigorously to ensure they do not affect the device’s communication flows. Mitigation strategies such as limiting SACK communications targeted at susceptible devices can also be executed, but similarly require careful consideration of the device’s functionality.

It is thus essential to reach out to identify all vulnerable devices on the clinical network and reach out to manufacturers to initiate the patching process. How you inventory and manage your devices will determine your capacity to manage the risk stemming from SACK Panic to your clinical network and coordinate remediation and mitigation activities.  

We have a dedicated team of researchers that are experts in cybersecurity and medical devices. They can answer any questions you have. And if you want to learn about how our solution quickly inventories your susceptible devices and alerts you of potentially malicious communications, contact us and we’ll follow up to ensure your clinical network is protected from SACK Panic attacks.

View our Threat Report for updates on new vulnerability disclosures and suggestions on how to mitigate their risks.

Stay safe.

Subscribe to our Threat Reports here.

WordPress Video Lightbox