Kata Container Security is Good, but There’s an Achilles Heel
In an age where security is paramount, addressing the vulnerabilities in Kata containers has never been more important.
What does container security have to do with ancient Greek mythology? Quite a lot if you recall the story of how the warrior, Achilles, was dipped as an infant into the River Styx by his mother, rendering him invulnerable except for the where she grasped him around the ankle.
In modern parlance, an Achilles’ heel is an uncharacteristic weakness in an overall strong system. Let’s apply that to Kata containers.
The Kata project was launched with considerable fanfare back in December of 2017, with version 1.0 being released the following May. It was described as a container runtime, designed to “build lightweight virtual machines,” and utilized hardware-level virtualization to keep containers isolated both from each other and from their host system. In this way, Kata is able to offer deeper isolation levels between individual workloads and achieves this to a greater extent than similar systems.
By doing so, the runtime strives to improve upon what has been seen—for a considerable length of time—as the Achilles’ heel of container systems: the reality that containerized workloads are not completely isolated from one another, a design weakness that theoretically leaves them open to security breaches should one container be compromised.
Of course, this level of isolation has always been possible via running each workload through its own virtual machine. The unique selling point of Kata, however, was that it could provide reliable isolation without the need for full virtualization. What’s more, Kata is compatible with Kubernetes and other container tech, thus making it easily integrated into a variety of systems and environments.
Understanding Kata’s Aims and Potential Vulnerabilities
The goal of Kata containers open source project and its associated community was always to create a standard VM (virtual machine) implementation that was agile and lightweight, and felt and performed like containers yet provided additional security and isolation. There’s little doubt about the fact that its arrival eased many of the concerns surrounding containers, especially when applied at scale.
However, no system is perfect, especially given the reality of just how fast black hat cybercriminals catch up and overcome the latest white hat security technology advances. As with any pioneering technology and use of data, there are weaknesses and blind spots that must be addressed. In an age where security is paramount and yet in which no shortage of internet users seemingly don’t want to learn the simple task of creating secure passwords, addressing the vulnerabilities in Kata containers and similar projects has never been more important.
Potential Breakouts and Vulnerabilities Identified
Several key vulnerabilities in Kata containers arise from the reality that they can be linked together, enabling hackers and attackers to achieve remote code execution (RCE) on the host, thus breaking out of the sandbox and taking control of live online assets. One leading security researcher, Yuval Avrahami, detailed these flaws in a keynote delivered at the Black Hat Asia conference, and explained how Kata’s flaws could potentially be exploited to compromise the systems of guest users.
The primary point concerned the similarities between virtual machines and containers, and how they allow software to run in individual environments. Containers, unlike VMs however, share the kernel of the host. Vulnerabilities in this kernel could lead to breakouts and attacks.
The open source containers central to Kata mitigate this risk by spawning the containers within a VM, meaning that even if an attack was to arise within a container, it would still be confined to the VM and wouldn’t be able to access the host kernel. It’s a logical and pragmatic approach, but Avrahami was keen to point out that it is far from foolproof, and requires even more layers of security and fail safing.
How Could Kata Containers Be Attacked?
Sandboxed containers are renowned for their use by cloud service providers and for multi-tenancy environments and have gained significant popularity as a result of their ability to provide services for multiple users on a single platform.
It is in this sense that Kata containers’ vulnerabilities become clear, as they are chained in a way that can not only potentially compromise the host kernel but also the machines of other users. Furthermore, because Kata doesn’t enforce cgroup for devices, guests are able to access the hardware of guest containers. As such, they could then go on to gain RCE over the host.
Thanks to the dentry and page cache implicit to Kata containers, however, attackers and bad agents will not be able to break out of the sandbox, even with access to the hard disk. This formed the basis for another of Avrahami’s key points: Because Linux uses page caches to avoid accessing the hard disk each time something needs to be obtained, an attacker must force the guest kernel to remove the page cache. This could be achieved—most straightforwardly—by flooding the page cache with detritus code to clear it, which in turn would cause the kernel agent to read from a malicious hard disk. The result? A sandbox breakout, which, when chained to a bad-acting image vulnerability, would allow the attacker to gain RCE on the host.
Furthering the Kata Attack
To take things further, an attacker would have to overwrite the image vulnerability to gain control of the guest VMs that would arise—something which presents a considerable danger for cloud services. Avrahami actually went ahead and carried out a mock of this attack, before revealing the vulnerabilities to the vendor so they could be patched.
This process allowed him to reveal the reality that containers are, essentially, only as secure as their configuration. Improvements need to be based around the dropping of unused privileges and removing capabilities that the containers don’t utilize. While sandboxes boost security by diminishing the attack surface, their imperfections should be faced with the understanding that attackers will always find their way to any potential vulnerability, because that’s what they do.