On June 18, 2019, Netflix researchers, together with MITRE, issued an advisory containing four vulnerabilities relating to how Linux handles TCP Selective-Acknowledgement (SACK) at the kernel level. These vulnerabilities affect devices running operating systems containing a large range of Linux and FreeBSD kernels. The most dangerous such vulnerability has been dubbed the "SACK Panic” vulnerability (CVE-2019-11477), which if exploited it can the device to crash courtesy of kernel panic.
The advisory also contained the "Linux SACK slowness" vulnerability (CVE-2019-11478), the "Low MSS Values slowness" vulnerability (CVE-2019-11479), and the "FreeBSD SACK slowness" vulnerability (CVE-2019-5599). Per the advisory, these vulnerabilities can be exploited to slow processing on targeted devices, enabling an attacker to inflict a Denial of Service and potentially crash the devices.
Affected devices span the gamut — from servers to IoT devices, phones to workstations, and much more. Pinpointing the exact devices exposed and the particulars of the exposure is complicated since it's difficult to accurately tell what kernel version a given device is running without consulting the OS vendor. Ostensibly, all devices with Linux kernels are affected by at least one vulnerability, while devices running Linux kernel versions 2.6.29 and later are prone to the more severe SACK Panic vulnerability.
According to Ido Hoyda, Head Cyber Analyst at CyberMDX, "In most hospitals, you'll find around 15% of total assets subject to this vulnerability." If you look more specifically at medical devices, "the number is even higher — somewhere around 30%," says Hoyda. "When you account for the fact that medical devices are more likely than other assets to have exceeded their support lifecycles or be otherwise un-patchable, you begin to appreciate how truly confounding these vulnerabilities can be."
Don't Panic, But We Have A Problem...
These vulnerabilities exist on the kernel level, with each OS using different versions that would require different patch construction. As such, to effectively address the vulnerability, separate patches will need to be verified and/or issued directly by device and software vendors for each and every differently affected product range.
For large organizations fielding thousands of vulnerable devices and sprawling across considerable physical space, keeping track of your affected devices, where they’re located, and from which manufacturers they were sourced is itself an enormous undertaking. Add to that the need to account for relevant model, software, and connectivity details and it's easy to understand why so many organizations choose to at best take half measures to address the issue, and at worst, ignore it altogether.
In a perfect world, you would have a complete and detailed list of all the affected devices in your arsenal and you would be able to call each and every vendor to ensure the availability of verified patches. You’d then install those patches and be on your way.
In real life though, your CMMS or inventory management system does not usually make for a very complete record of your connected devices. You’ll struggle to get a handle of the vulnerable devices and then you’ll be pained to pull the necessary device and software component details to know which vendors you’ll need to reach out to and what you’ll need to ask them.
Of course, as mentioned above, you’ll have many devices that already reached the end of their support lifecycle, for which you’ll be unable to get verified patched. Then you’ll be told by many or even most of the vendors you contact that they haven’t issued any patches and they can’t vouch for the security or effectiveness of third-party patches. On top of that, you’ll need to figure out what to do about your devices that simply won’t support patches of the sort required.
When patches cannot be implemented, you’ll need to look to mitigation strategies and to enforce these effectively without interfering with your normal, legitimate workflows. You’ll need to craft a custom approach based on an intimate knowledge of your network architecture, operational norms, and acceptable trade-offs. Even when these mitigations are successfully implemented, they won’t be perfect.
For example, NAC and firewall based restriction regimes can only protect you from threats coming into your network from the outside; internally originating threats can be contained with smart network micro-segmentation and security policies, but they cannot be altogether prevented.
Not the Same Old Vulnerability
So much of the complexity involved in mitigating this type of risk exposure stems from the open-source, decentralized development ecosystem that comes with Linux. By contrast, if we were talking about a Windows vulnerability, like BlueKeep, there would still be some degree of special consideration required for the types of devices running the OS, but by and large, patches would be centrally issued and managed to cover most of the attack surface.
For SACK Panic and similar vulnerabilities, there is simply no one-size-fits-all solution. Blocking selective acknowledgement is a good start, but it won't deliver anything close to complete protection. Most organizations that are serious about tackling these problems will need to work closely with security experts — whether from within their organization or from a product/service provider — to find the combination of solutions that work best for them.
In the case of these four vulnerabilities disclosed by Netflix via MITRE, the situation is made worse by the fact that the path to exploitation is incredibly straight forward. In fact, all the basic ingredients for an attack are laid out in the disclosure itself per the vulnerability description. The easy accessibility of such vulnerabilities also increases the attack surface.
Best Practices for Surviving SACK Panic
Because the vulnerabilities in the Netflix advisory are so difficult to address generally, without a case-by-case examination, they do a good job illustrating the importance of good network hygiene and smart management practices. Maintaining both is the best way to minimize risk exposure from the start and make it easier to enact targeted controls and restriction to address specific threats.
Having a well-structured and well-managed network also makes it easier to detect and respond to events in real time based on pre-configured triggers or automatically monitored baseline deviations and threat signatures.
Here are seven steps you can and should take to immediately and preventatively improve your cyber posture:
- The first and most important step in protecting against threats, both known and unknown is to take and maintain a complete inventory of your connected devices. This should include hardware, firmware, OS, software, and network configuration details.
- Wherever possible, you should look to enrich your itemized device data set with information from MDS2 forms, as well as software and hardware bills of material.
- You'll want to make sure that you have a well-defined procedure in place and enforced for adding new devices to your network. It's important that such deployments are captured and reflected in your inventory management system or CMMS.
- To supplement, verify, and backup those procedures, you should have some sort of asset discovery and mapping solution that sits on top of your network.
- You should integrate the National Vulnerability Database (NVD) feed into your central management dashboard.
- You'll want to make sure you have all the appropriate perimeter defenses in place protecting your network, but you'll also want to make sure that your network is properly micro-segmented throughout its interior. Normally that will mean building on your asset mapping solution to identify devices with common risk profiles and similar operational functions to group together under shared security policies.
- Maintaining proper clinical awareness of these devices and their network context will be critical in fine-tuning those security policies for best effect. For example, for the "Low MSS Values slowness" vulnerability, one possible mitigation involves denying traffic requests that exceed a Maximum Segment Size of around 500. This mitigation should effectively deny the vulnerability expression, but depending on the device and it's normal use, it might also restrict legitimate network communications and undermine the machine's clinical utility.
There may be no silver bullet when it comes to protecting your organization from vulnerabilities the likes of "SACK Panic”, but taken together, these seven steps will help ensure that whenever new vulnerabilities are disclosed, you can quickly tell how and where they impact your organization; putting you in position to swiftly identify and install the appropriate patches where available, while pursuing best practice mitigations wherever patching is not an option.