About Meltdown and Spectre
Following the trend of ‘branding’ vulnerabilities, Meltdown and Spectre vulnerabilities (CVE-2017-5754, CVE-2017-5753, and CVE-2017-5715) are ‘brand’ names given to currently known variants of vulnerabilities of a similar nature, related to speculative execution. The general idea is rather simple: In the case of conditional execution (the selection of an execution path based on certain conditions) most modern CPUs ‘speculate’ the right execution path, so that while the condition is being evaluated, the CPU continues executing instead of just being idle, resulting in more optimized performance. If the guess was wrong, the CPU tries to discard the effects of the execution. The core of the problem is that not all effects are discarded, leaving some results of the execution up for grabs to malicious code. The actual details, obviously, are way more complex, but the above describes the general idea.
In the Spectre paper, researches presented a JavaScript proof-of-concept that “... when run in the Google Chrome browser, allows JavaScript to read private memory from the process in which it runs…“
I hope this example illustrates the seriousness of the issues found. For deep dives into this topic you can read the papers at https://meltdownattack.com/ and the Google Zero Project blog.
The Meltdown and Spectre vulnerabilities may also affect production servers running containerized applications. This may result in attacks that enable a malicious or a compromised container to steal secrets or credentials from other containers running on the same host!
To mitigate this risk, organizations should install security fixes released by hardware and OS vendors. Notice though, that since the vulnerabilities are rooted in a CPU’s execution optimization feature, all of the fixes have a performance impact. So while it highly advisable to install the fixes, one should be aware of the performance impact.
How Do These Vulnerabilities Apply to Container Environments?
But what about other measures? How can you protect yourself against these and future vulnerabilities in container environments?
The (only relatively) good news is that both vulnerabilities provide read capabilities, not write capabilities. So planting malware is not something that is directly enabled by these vulnerabilities, but data exfiltration certainly is. Let’s see how this can be stopped if you’re using containers.
The Meltdown and Spectre vulnerabilities break the basic sandboxing assumptions of containers and VMs, but containers also provides an opportunity to more easily detect an exploit attempt of those vulnerabilities, as well as mitigate and limit its effects:
- An obvious first step is to only allow trusted images into your environment. Scan images for vulnerabilities, and ensure that only the images that passed security scans can run in your environment and cannot be changed. Aqua customers enjoy these capabilities out of the box.
- At runtime, use a whitelisting approach to only allow legitimate behavior. By doing this, any abnormal process, such as attempts to access files that aren’t normally accessed, attempts to elevate privileges on the host, or attempts to establish outbound network connections, will not be allowed.
At Aqua we do this using a combination of declarative information found in the image itself, as well as an automated machine-learned baseline that creates the whitelisting profile, and any violation of that profile can be blocked without freezing or killing the container. - Even if the attacker successfully mounts the attack and manages to access data, such as credentials, that data still needs to be exfiltrated. This is where network controls such as a container-level firewall can make it endlessly more difficult to find an exfiltration path. Aqua’s container firewall (see below) does that by ensuring that container-to-container communication is only permitted on a “need to know” basis - just like processes on the host it is whitelisted based on application context. Additionally, egress network is not enabled by default - only if needed, and that too only to approved destinations (IPs or services).
To summarize - in the case of Meltdown and Spectre, containerized applications are vulnerable. However, containers make it much easier to prevent the exploitation of these vulnerabilities, as well as of unknown zero-days that are, no doubt, lurking in the shadows.
