CopyFail: From Pod to Host

URL SCAN

COPYFAIL: FROM POD TO HOST — Xint.io Security Research

FIRST LINE: "Two weeks ago, we disclosed Copy Fail, a new and exceptionally dangerous Linux local-privilege escalation vulnerability."

THE DISSECTION

This is a technical post-exploitation guide for a Linux kernel vulnerability with a specific, devastating capability: deterministic, cross-container page cache poisoning. The article does three things simultaneously:

1. Extends the scope of the original Copy Fail disclosure beyond simple privilege escalation to full cross-pod compromise and container escape
2. Documents the architectural flaw that makes this possible: the kernel page cache is not namespaced, and container layer deduplication creates shared address spaces across tenants
3. Provides weaponization patterns for both cross-container poisoning (Scenario 1) and runc-based container escape (Scenario 2)

The prose is clinical, methodical, and the PoC output (host-level reverse shell via containerized attack) reads like a lab report. This is not fearmongering. The mechanism is real, deterministic, and operates below the detection layer of most security tooling.

THE CORE FALLACY (in the broader security discourse this targets)

The dominant security model assumes namespace isolation = security boundary. Containers inherit this assumption from their design premise: you can run untrusted workloads with hard tenancy separation because mount/PID/network/user namespaces create isolation.

Copy Fail shatters this. The page cache is a shared kernel data structure invisible to namespaces. When container runtimes deduplicate layers by content hash (containerd, CRI-O do this), pods on the same node that share a base image layer also share the same underlying inode and address_space. A 4-byte write into that shared page cache is visible to every container that touches the same file — regardless of namespace, RBAC, or admission policy.

The fallacy: treating container density optimization as equivalent to security isolation. Layer deduplication exists for efficiency (storage cost reduction, image pull speed), not safety. The security model was built on an artifact of the implementation.

HIDDEN ASSUMPTIONS

1. Kernel page cache = trusted shared memory. It isn't. It's a kernel data structure that crosses every container boundary on the node.
2. Image layer identity = isolation boundary. It isn't. The actual isolation boundary is the backing inode, which layer deduplication collapses across unrelated workloads.
3. Agent-less scanning catches compromise. It doesn't. Disk hashing, registry scanning, offline取证 all operate below the page cache layer. The modified bytes live only in kernel memory.
4. RBAC namespace separation = meaningful access control. It's not, when a pods/create permission in Namespace A lets you poison workloads in Namespace B via shared layer + node co-location.

SOCIAL FUNCTION

This is transition revelation — technical evidence that container architecture is fundamentally less isolated than enterprise multi-tenant infrastructure relies upon. It's not copium or lullaby. It's a forensic analysis of a structural flaw that undermines the security assumptions baked into every major Kubernetes deployment.

The audience is cloud operators, security engineers, and platform teams running multi-tenant clusters. The message: your isolation is thinner than you thought, your detection tooling has blind spots, and the fix is not a config change.

THE VERDICT (DT Lens)

Immediate Structural Assessment

The Copy Fail mechanism reveals a critical architectural tension in cloud infrastructure:

The efficiency/security tradeoff has collapsed. Container layer deduplication is an optimization that creates attack surface invisible to the security model built on top of it. The competitive pressure to maximize pod density (compute cost reduction) generated an architectural shortcut whose security implications were not fully modeled.

The result: cross-tenant compromise is mechanistically possible at the node level, bypassing RBAC, namespace isolation, and most detection tooling.

DT Framework Relevance

This maps to three DT pressure vectors:

1. Competitive pressure degrading defensive architecture. The incentive structure (compute efficiency, storage cost) created shared attack surface that individual operators cannot discover or control. Defense requires kernel patches, architectural changes, or VM migration — none of which is cheap or fast.

2. Sovereign vs. Servitor asymmetry. Cloud providers (AWS, GCP, Azure EKS/GKE/AKS) are Sovereign: they control the node kernel, can push patches centrally, and can engineer around the vulnerability at the infrastructure layer. Individual tenants are Servitors: they depend on provider patching timelines, have no visibility into shared page cache state, and face defensive asymmetry — the attack is deterministic, the defense is expensive and slow.

3. The "verify the security boundary exists" problem. The vulnerability exploits a gap between the advertised security boundary (namespace isolation) and the actual security boundary (kernel data structures). This is a recurring theme in cloud-native security: the abstract model and the implementation diverge, and the divergence is exploitable.

Specific Implications

The Detection Gap Problem

Agent-less tools, registry scanners, disk hashers, and offline取证 all see unchanged on-disk inodes. The compromise lives only in the kernel page cache. This is a visibility gap with systemic consequences: organizations cannot audit their way out of this vulnerability. The only reliable detection is runtime EDR watching process execution, which most containers explicitly do not run.

VIABILITY SCORECARD (for cloud-native infrastructure)

SURVIVAL PLAN (for operators and organizations)

For Servitor entities (tenants on shared infrastructure):
- Assume the page cache is compromised or compromiseable
- Demand EDR inside pods, not just at the node level
- Request and verify kernel patch status from providers
- Treat DaemonSets as high-value attack surface: audit hostPath mounts, minimize DaemonSet count and blast radius
- For hard tenancy: migrate to VM-based isolation where multi-tenant separation is non-negotiable

For Sovereign entities (cloud providers, platform teams):
- Accelerate kernel patch deployment; this is not a "nice to have"
- Disable AF_ALG at the node level (seccomp profile) for non-crypto workloads
- Engineer toward VM-based tenancy for untrusted workloads, not container-hardening that addresses symptoms
- Build page cache integrity monitoring as a first-class node observability primitive

The structural fix is architectural, not patch-based. The page cache sharing that makes this attack possible is baked into the container runtime design. Patching Copy Fail closes this specific hole. The underlying assumption (namespace isolation = security boundary at the kernel memory layer) remains broken. Expect similar vulnerabilities until the isolation model is reformed.

FINAL VERDICT

This is a class-breaking vulnerability in the container security model. Not because it's novel (page cache sharing is well-known) but because the economics of container deduplication made it exploitable at scale across multi-tenant infrastructure, and the security model built on top of namespaces never accounted for it.

The post-WWII cloud architecture assumes you can sell "secure multi-tenancy" via namespace isolation. Copy Fail demonstrates that the isolation is real for some things and illusory for others. The page cache is the others. That's not a bug. That's the architecture.