Containers Offer Good Protection Against Spectre and Meltdown Attacks if You Know What to Do
Software containers can offer some respite against Spectre and Meltdown attacks — but without the help of critical security tools and practices, they remain relatively easy targets.
“Containers are harder to exploit and are easier to protect than other systems, such as virtual machines, are. But I’m not trying to say you have nothing to worry about, either,” said Michael Cherny, head of research for, Aqua. “Containers are like a single-door house. In comparison, a virtual machine on the cloud can have many doors you can open with Spectre and Meltdown.”
Still, containers, of course, are vulnerable to Spectre and Meltdown attacks in ways virtual machines and other systems are, as intruders gain access through security holes in Intel, AMD, and ARM devices on which the software runs. In the case of Spectre attacks, containers are penetrated by exploiting discarded CPU code and executing that erroneous code from the core processors. Meltdown attacks involve access and exploitation of instructions that are then leaked to the physical memory cache.
“Whether it is on a container or a virtual machine, the point is really moot since these vulnerabilities are silicon-based,” said David Lawrence, security lead at Docker. “The main fix for these types of vulnerabilities is in the OS kernel and CPU hardware level for Windows, macOS, and Linux. We thus recommend you follow standard procedures for operating system kernel upgrades as quickly as possible.”
One issue specific to containers is their runtimes were designed to manage their lifecycles, rather than to detect the malicious behavior of individual-running containers, said Gadi Naor, Chief Technology Officer and co-founder for Alcide.
Like the different types of bacteria that cause Lyme disease in humans, both black and white hackers continue to create variants of Meltdown and Spectre that existing patches cannot yet fix.
“The eye-opening reality with Meltdown and Spectre is that CPUs will continue to ship with these vulnerabilities in the next few years,” Naor said. “For containerized deployments, updating the underlying operating system with the relevant patches and the underlying performance penalty is the first stop.”
Indeed, the installation of patches will cause performance lags, the magnitude of which remains to be seen. “From a performance standpoint, as far as processor speed goes, opinions vary. It obviously depends on the payload you run, but there’s no one number quantifier,” Cherny said. “All we know now is the patches are slowing them down or are going to slow them down even more in the future.”
A Long Road Ahead
It is also often overlooked that available Meltdown and Spectre patches for kernels will be unable to fix container vulnerabilities in the future, since different variants of Meltdown and Spectre will exist. Like the different types of bacteria that cause Lyme disease in humans, both black and white hackers continue to create variants of Meltdown and Spectre that existing patches cannot yet fix.
“The industry is still waiting to see how much these new updates are going to work,” Cherny said. “The dust has not settled. We’re just doing preliminary tests and waiting on the numbers.”
However, the good news is that deployment of CPU kernel patches for containers, as they become available, is relatively simple to do.
“While patching for Spectre and Meltdown will not consist of one but many fixes, downloading kernel patches with containers are much easier to do compared to virtual machines, for which you have to patch every single virtual machine kernel for every single application,” said Eric Han, vice president, product management, Portworx. “With containers, the number of patch installations go down because you have many applications on a shared kernel. Deployment is much more immutable and predictable.”
Still, the emergence of Spectre and Meltdown, as well as future yet-to-be-revealed threats, point up to how container developers, as well as storage firms in general, need to work more closely together with security companies, Han said.
“Spectre and Meltdown really show how, as an industry, we need to have the developer ops and security ops worlds come together,” Han said. “I think you are going to see more partnerships between security and container companies. These types of partnerships will just make container security management that much more seamless.”
Garbage In, No Garbage Out
In addition to developing and implementing patches on a chip level, tighter use of existing security tools can go a long way in protecting containers from Spectre and Meltdown. The beauty of containers is also how they are largely designed to isolate data and applications. As their name implies, containers are useful for detecting and then containing suspect data traffic, among other things. Additionally, tools such as scanning and whitelisting are particularly adept at preventing an intruder from successfully launching a Spectre or Meltdown container attack.
With whitelisting, attempts to gain unusual access to files, to extend admin privileges on the host, or to establish outbound connections is mitigated in the event of a Spectre- or Meltdown-generated security hole. “Whitelisting is particularly important to ensure data is note ex-filtrated from a container,” Cherny said. “The appropriate alarms are sent when anything unauthorized or even unusual is attempted. “
Scanning tools help to ensure only trusted images are allowed to gain access. “You must only allow images you have drafted into your environment,” Cherny said. “In order to exploit Spectre or Meltdown, you need to be able to run local code. If an image is not scanned, it cannot run in the container.”
As a final stopgap, classic container firewalls can serve as a fallback by preventing data, once compromised, from being transferred from one container to another or elsewhere on the network, in ways traditional firewalls do. Just like whitelisting images before they can be stored on a container, a firewall will thus prevent a smart chip-level Spectre or Meltdown attack, even once the data is ex-filtrated, Cherny said.
Freedom vs. Security
Despite their utility in being able to lock down containers against Spectre and Meltdown, overzealous scanning and whitelisting can serve to limit their flexibility for data sharing.
Exploiting Speculative Execution via JavaScript
|
1 2 3 4 5 |
if (index < simpleByteArray.length) { index = simpleByteArray[index | 0]; index = (((index * TABLE1_STRIDE)|0) & (TABLE1_BYTES-1))|0; localJunk ^= probeTable[index|0]|0; } |
Source: University of Pennsylvania, University of Maryland, Graz University of Technology, Cyberus Technology, Rambus, Cryptography Research Division, University of Adelaide, and Data61
“Protecting containers against Spectre and Meltdown attacks is a double-edged sword: in one way, you want to make sure your developers are productive so they can take advantage of the best-in-class libraries and respond to business concerns. But this also means you sometimes need to be ready to manage containerized applications from sources you haven’t completely vetted,” Han said. “Scanning and whitelisting tools are critical, of course, but you have to balance security concerns with productivity, so you need to worry about both. With Spectre and Meltdown, it also especially good to know you have more than one tool to work within the event of an attack.”
At the end of the day, containers represent a good balance between utility and the security they offer for protection against Spectre and Meltdown, as well as other attacks, Cherny said. “Containers represent a peculiar situation — they are relatively easy to protect, but they will always have their vulnerabilities to exploitable CPU code,” Cherny said. “But if you have the right tools and the right protocols you are in a better place.”
Alcide, Aqua, and Portworx are sponsors of The New Stack.
Feature image via Pixabay.
