Outwitting the New CRI-O Vulnerability

If you’re a CRI-O user, there’s a newly discovered vulnerability that could affect you. It’s called CVE-2022-0811 and it was discovered by CrowdStrike cloud security researchers. While it can’t be exploited by just anyone, it can still wreak havoc in your cluster node. We talked to Rory McCune of Aqua Security about how the vulnerability operates and how you can protect yourself.

How CVE-2022-0811 Puts You at Risk

If you’re a cluster operator using CRI-O to launch and manage clusters, you can normally manage each container and modify internal parameters within certain white-list restrictions. CVE-2022-0811 breaks through those limits—or rather, allows the attacker to do so.

But not just any stranger can use the vulnerability to achieve container breakout. Attackers must be a regular user of the cluster, with enough access to create a new application. “If attackers have the ability to create pods in a Kubernetes or an OpenShift cluster, they can break out to the underlying cluster node, effectively escalating their privileges,” McCune says. “Normally, they should not be allowed to do that. But they go from regular user to node superuser.”

How do they do it? The vulnerability allows them to slip past safeguards and change or set up a parameter by adding a “+” character and then setting additional dangerous parameters. Having escalated their privileges, they can move anywhere in the cluster and take control of it. They can run a malware script, steal data or alter the underlying machine in some other way.

Closing the CVE-2022-0811 Gap

The CRI-O project has issued a patch, which should be the first step for anyone affected. “The correct message is always, ‘Please, patch,’” says McCune. “But we know that’s not always possible as patching can be easier said than done.”

If you can’t upgrade to a patched version of CRI-O right away, you can deploy layers of protection, such as admission control. Software like Kyverno or Open Policy Agent (OPA) allows you to filter workloads and block the ability of the attacker to change parameters. To escape the container, the attacker has to set custom sysctls values in a manifest. So if the workloads running in your cluster don’t need to set custom sysctls, an easy fix is to block any attempt to set them.

“Kyverno or OPA both have policies to do that,” McCune says. “You just add that policy to your cluster. That’s what I’d do if I was trying to mitigate.”

If your workloads do require custom sysctls? You can try to block pods with the “+” character. However, McCune warns, this is more of a Band-Aid for someone planning to patch in a few days, rather than a permanent solution. “You can try to filter out the plus sign,” he says. “But I wouldn’t bet my life on it, because blacklisting characters is a risky thing to do.”

Preparing for a Growing Threat Landscape

So how serious is this vulnerability? CRI-O users, particularly in Red Hat environments, will want to take action. So will anyone with multi-tenancy clusters, which by nature means you’re dealing with different groups of users who shouldn’t be able to reach other people in the cluster. But patching and the other protections mentioned should do the trick.

A final word: This vulnerability isn’t unique. McCune warns that the cybersecurity threat to containers is growing—and that cluster operators need to keep an eye on new vulnerabilities and keep up with patching.

“Cluster operators need to be on their game,” he says. “We’re seeing attackers pay more attention to containers. A couple of years ago it was quiet and we hadn’t had many container breakout vulnerabilities in a while. Since January this year, I’ve seen three or four.”