CrackArmor: Our Assessment for Managed Kubernetes Workloads

On March 12, the Qualys Threat Research Unit publicly disclosed nine vulnerabilities in the Linux kernel’s AppArmor security module, collectively named CrackArmor. The flaws have existed since kernel v4.11 (2017) and affect every distribution that ships AppArmor by default — Ubuntu, Debian, and SUSE — putting an estimated 12.6 million systems in scope.

bifrost generates tailored AppArmor profiles for Kubernetes workloads. Our customers rely on these profiles to enforce least-privilege at the container level, so we have been tracking the CrackArmor disclosure closely. Here is our assessment of what it means for managed Kubernetes environments and what you should do about it.

What CrackArmor actually is

The root cause is a confused deputy problem in how AppArmor exposes its management interface. The pseudo-files under /sys/kernel/security/apparmor/ (.load, .replace, .remove) can be opened for writing by any unprivileged user. Permission checks only happen when data is written, not when the file descriptor is opened. If a privileged process can be tricked into writing to an already-opened descriptor, an attacker can load, replace, or remove arbitrary AppArmor profiles.

From that foundation, Qualys demonstrated several escalation chains: silent removal of profiles from running services, a userspace privilege escalation to root through sudo and Postfix in under five seconds, a kernel use-after-free that achieves root through memory corruption, container escape via crafted namespace profiles, and a denial-of-service that triggers kernel panic through recursive stack exhaustion.

The headlines are alarming. The practical exploitability in a well-configured Kubernetes environment is more nuanced.

Our assessment for managed Kubernetes

We see two potential attack paths against Kubernetes nodes. One of them we can effectively rule out for most deployments. The other requires specific preconditions that no one should be running without strict justification.

Host-level exploitation: effectively ruled out

The userspace attack chains (tricking sudo or su into acting as the confused deputy) require an unprivileged user to be logged in to the node itself. In managed Kubernetes, regular users should not have shell access to the underlying hosts. If your nodes are managed by a cloud provider and only cluster administrators have SSH access, this path does not apply. We do not recommend allowing standard users access to Kubernetes nodes, and this is one more reason why.

Container escape: possible but conditional

Ubuntu’s security team has stated that the kernel-level AppArmor vulnerabilities can theoretically be exploited from within a container without a cooperating privileged userspace application, but that this has not been practically demonstrated at the time of writing.

Our assessment is that for a container-based exploit to succeed, specific preconditions must be in place. The container would need to be running with one or more of the following: privileged mode, hostPID: true, CAP_SYS_ADMIN, or a host path mount of /sys into the container. These configurations grant the container access to the kernel’s AppArmor interface that the exploit requires.

Beyond that, the attacker must first achieve remote code execution inside the container — through a supply chain compromise, a vulnerability in the workload, or a malicious container image. bifrost’s runtime protection makes this initial step substantially harder to carry out before the attacker can even attempt a CrackArmor exploit.

In short: the exploit chain requires elevated container privileges that we do not recommend anyone use unless there is strict operational need, combined with an initial foothold that runtime protection is specifically designed to prevent.

What bifrost profiles mean in this context

bifrost-generated AppArmor profiles are not an attack vector for CrackArmor. The vulnerabilities exist in the kernel’s enforcement mechanism, not in any profile’s content. A well-crafted bifrost profile continues to provide the same least-privilege enforcement it always has — the profile itself is sound.

What CrackArmor does highlight is that AppArmor enforcement alone should never be your only isolation boundary. Defense in depth matters. bifrost profiles are one layer. Pod Security Standards, network policies, and proper node hardening are the others. Together they make the preconditions for a successful CrackArmor exploit very difficult to achieve.

What you should do now

Patch your nodes. Kernel updates addressing all nine vulnerabilities are available for Ubuntu 24.04 LTS and Debian. Updates for remaining Ubuntu releases are in progress. Apply both the kernel patches and the userspace mitigations for sudo and su as soon as they are available for your distribution. Many organisations rely on a cloud provider for the management of node images in their managed Kubernetes clusters. If that applies to you, monitor your provider’s release channels for updated node images that include the patched kernels, and roll your node pools forward as soon as those images are available. In the meantime, regular node maintenance — keeping nodes up to date with the latest available images and recycling them on a routine schedule — remains one of the most effective baseline practices for reducing exposure to vulnerabilities like these.

Audit container security contexts. Confirm that no workloads are running with privileged mode, hostPID: true, CAP_SYS_ADMIN, or unnecessary host path mounts unless there is a documented and reviewed justification.

Monitor and block access to the AppArmor interface. Deploy file-integrity or audit monitoring on /sys/kernel/security/apparmor/ to detect unauthorized profile modifications. As an additional safeguard, bifrost customers can add an org-wide DENY rule for /sys/kernel/security/apparmor/* to their bifrost policy. This will trigger if any process from within a container attempts to access or modify the AppArmor pseudo-files, providing both detection and prevention against this specific exploit path.

Restrict node access. Verify that only cluster administrators have SSH access to the underlying nodes. Standard users should interact with the cluster through the Kubernetes API, not through host-level access.

We are continuing to monitor the situation as additional kernel patches are released and as the community assesses whether practical container escape exploits emerge. We will update this post if our assessment changes.