If you are a CRI-O user, a recently discovered vulnerability could affect you. It’s called CVE-2022-0811 and it was discovered by CrowdStrike cloud security researchers. Although it cannot be exploited by just anyone, it can still wreak havoc in your cluster node. We spoke to Rory McCune of Aqua Security on how the vulnerability works and how you can protect yourself.
How CVE-2022-0811 puts you at risk
If you are a cluster operator using CRI-O to launch and manage clusters, you can normally manage each container and change internal settings within some whitelist restrictions. CVE-2022-0811 crosses these boundaries– or rather, allows the attacker to do so.
But not just any outsider can use the vulnerability to pull off a container evasion. Attackers must be regular users of the cluster, with sufficient access to create a new application. “If attackers have the ability to create pods in a Kubernetes or OpenShift cluster, they can access the underlying cluster node, increasing their privileges,” McCune says. “Normally they shouldn’t be allowed to do that. But they go from regular user to node superuser.
How do they do? The vulnerability allows them to bypass protective measures and modify or configure a setting by adding a “+” character and then setting additional dangerous settings. After escalating their privileges, they can roam anywhere in the cluster and take control of it. They can run a malicious script, steal data, or otherwise modify the underlying machine.
Close the gap CVE-2022-0811
The CRI-O project has released a fix, which should be the first step for anyone affected. “The correct message is always, ‘Please patch,'” McCune says. “But we know that’s not always possible, as fixes can be easier said than done.”
If you cannot upgrade to a patched version of CRI-O immediately, 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 attacker’s ability to change settings. To evade the container, the attacker must set custom sysctls values in a manifest. So, if the workloads running in your cluster don’t need to set custom sysctls, a simple solution is to block any attempt to set them.
“Kyverno or OPA both have policies to do that,” McCune says. “You just need to add this policy to your cluster. That’s what I would do if I was trying to tone it down.
If your workloads require custom sysctls? You can try blocking pods with the “+” character. However, warns McCune, this is more of a band-aid for someone planning to put a fix in a few days, rather than a permanent fix. “You can try filtering out the plus sign,” he says. “But I wouldn’t bet my life on that, because blacklisting characters is a risky thing to do.”
Preparing for a growing threat landscape
So how serious is this vulnerability? CRI-O users, especially in Red Hat environments, will want to take action. The same will be true for anyone with multi-tenant clusters, which inherently means that you are dealing with different groups of users who should not be able to reach other people in the cluster. But the patches and other protections mentioned should do the trick.
A final word: this vulnerability is not unique. McCune warns that the cybersecurity threat to containers is growing and cluster operators need to keep an eye out for new vulnerabilities and track patches.
“Cluster operators have to be on their game,” he says. “We are seeing attackers pay more attention to containers. A few years ago it was quiet and we hadn’t had many container evasion vulnerabilities in a while. Since January of this year, I have seen three or four.