Hackers could exploit a Linux kernel bug to escape Kubernetes containers and access critical resources; however, the threat is minimized as any attacker needs to have the specific Linux capability CAP_SYS_ADMIN.

The high-severity Common Vulnerabilities and Exposures (CVE) 2022-0185, first reported by security publication BleepingComputer, affects all Linux kernel versions from 5.1-rc1 to the latest releases (5.4.173, 5.10.93, 5.15.1).

The public exploit code for the issue is expected to be released soon by Crusaders of Rust (CoR), the team which discovered the vulnerability, meaning all systems at risk from this issue should apply the patch as soon as possible.

A container breakout is a privilege escalation attack that leverages flaws in a containerized environment to gain access to its hosting environment.

Containers are intended to keep the application living inside it isolated, both from other applications on the host system and to protect the host from application misbehavior or compromise. Escaping the container breaks that model and enables access to other parts of the system.

Brendan Creane, head of engineering at Tigera, a provider of security and observability for containers, Kubernetes and cloud, says this is a serious issue, as the entire concept of a containerized environment is to allow potentially untrusted data to be processed and any potential exploits (denial of service, arbitrary code execution, etc.) be limited to within the container.

“Having a container breakout breaks that concept, which means an attacker can escape the containerized environment and gain access to the host,” he says. “This can potentially allow the attacker to access other containers or access sensitive data on the host.”

Breaking Out

If a malicious actor can escape the container and access the underlying host, they can use that as a launching point to search for additional vulnerabilities in the overall cluster.

“That’s why container isolation, or the guarantee that a compromised container can’t access other resources on the host or in the cluster, is an essential part of the contract for securing Kubernetes,” Creane says.

In addition to the scenario above, Creane explains that managed Kubernetes providers rely on container isolation to enforce separation of concerns within a host that’s potentially shared by multiple customers.

“In other words, if Client A can escape their container and access the host, they can potentially compromise services running on that particular host that are owned by Client B,” he says. “Since the security boundary between the container and host is lost, the attacker no longer needs to care if the workload they have compromised is containerized or not.”

Limits to Container Security

Casey Bisson, head of product growth at BluBracket, a provider of code security solutions, pointed out container security has been improving, but many of the benefits of containers come from the very flexibility that limits the security they provide.

He notes that containers continue to lag behind virtual machines (VMs) in securely isolating workloads from each other on the same hardware.

Bisson says operators and AppSec teams will need to evaluate and balance risks against infrastructure costs for their applications.

“It might work well and provide efficiencies to run containers from the same team or group of teams on the same cluster, but many people are likely to continue to isolate workloads onto separate clusters or use placement rules to separate containers from different teams on different VMs,” he says.

Bisson says the day may come where container security matches that of VMs, but adds that VMs have had security flaws too, and even isolating workloads on different hosts has never really been enough to keep hackers at bay.

From his perspective, comprehensive security goes beyond the runtime environment to include supply chain protections, dynamic and static code analysis, efforts to securely manage secrets and more.

“We see that code is now the largest and least-protected threat vector,” he says. “Attackers are targeting upstream components that are unguarded so they can then infiltrate those who use the components. Kubernetes, unfortunately, is a perfect target because of its widespread use. Luckily, the community has even more focus on security in Kubernetes so the capabilities will continue to develop.”

Mike Parkin, engineer at Vulcan Cyber, a provider of SaaS for enterprise cyber risk remediation, says that while security vulnerabilities are discovered every day, it’s hard to predict which specific ones will become weaponized by threat actors and used in the wild.

“That’s why patching security vulnerabilities—whether in standard systems or containerized environments—is so important,” he says. “You must assume the worst and keep your systems up-to-date.”

Parkin explains that with container environments, attackers get a choice: Compromise the application itself and use that for their end goal or go after the host system the container is running on and expand from there.

“Those aren’t mutually exclusive targets, either,” he adds. “Defenders need to consider the security of both the applications and the virtualization platform itself. Those aren’t mutually exclusive defenses, but they do require a different focus and a different set of skills.”