Dirty Frag (CVE-2026-43284) — Kubernetes 컨테이너 탈출 PoC

기본 권한의 비특권 Kubernetes Pod가 Amazon EKS에서 노드 수준 코드 실행을 달성할 수 있음을 입증하는 개념 증명입니다. 공유 컨테이너 이미지 레이어를 통한 Dirty Frag Linux 커널 페이지 캐시 손상 취약점을 악용합니다.

핵심 공격 원리는 다음과 같습니다: 공격자가 제어하는 컨테이너와 이미지 레이어를 공유하는 권한 있는 DaemonSet은 컨테이너 탈출에 무기화될 수 있습니다. 이 PoC는 kube-proxy를 구체적인 예로 사용하지만, 이 기법은 클러스터의 모든 권한 있는 워크로드에 일반화됩니다.

Amazon EKS(커널 6.12.80)에서 검증됨 — 비특권 Pod가 권한 있는 kube-proxy DaemonSet을 통해 호스트 파일시스템에 [*] success를 기록합니다:

EKS PoC

면책 조항: 이 저장소는 교육 및 방어 목적으로만 게시됩니다. 소유한 시스템 또는 명시적 테스트 승인을 받은 시스템에서만 사용하십시오.

배경

Dirty Frag (CVE-2026-43284)는 xfrm/ESP 수신 경로의 Linux 커널 페이지 캐시 손상 취약점입니다. 영향을 받는 경로에서 esp_input()은 frag_list가 없는 비선형 skb에 대해 skb_cow_data()를 건너뛸 수 있으며, 이를 통해 crypto_authenc_esn_decrypt()가 splice()를 통해 도달한 페이지 캐시 페이지에 공격자가 제어하는 4바이트를 저장할 수 있습니다.

디스크의 파일은 수정되지 않습니다. 손상된 바이트는 커널 페이지 캐시에 존재하며, 동일한 캐시된 파일 페이지를 나중에 읽는 프로세스에 의해 관찰됩니다.

원래 취약점에 대한 자세한 내용은 V4bel/dirtyfrag를 참조하십시오.

공격 원리

이 공격은 Kubernetes 클러스터에서 흔히 공존하는 세 가지 속성을 악용합니다:

커널 페이지 캐시 손상 (CVE-2026-43284) — 비특권 프로세스(사용자 네임스페이스 지원 포함)는 xfrm/ESP splice 경합을 통해 읽기 전용으로 열 수 있는 모든 파일의 메모리 내 캐시된 페이지를 덮어쓸 수 있습니다.
이미지 레이어 공유 — 컨테이너 런타임(containerd, CRI-O)은 overlay 파일시스템을 사용하며, 동일한 이미지 레이어는 컨테이너 간에 동일한 페이지 캐시 페이지에 매핑됩니다.
권한 있는 DaemonSet — 많은 클러스터가 향상된 권한(privileged: true, hostNetwork: true, 광범위한 capabilities 등)으로 DaemonSet을 실행하며, 주기적으로 이미지에서 바이너리를 실행합니다.

이러한 조건이 일치하면 비특권 Pod가 공유 이미지 레이어의 바이너리를 손상시킬 수 있고, 동일한 노드의 권한 있는 DaemonSet이 손상된 바이너리를 향상된 권한으로 무의식적으로 실행하여 완전한 노드 수준 코드 실행을 달성합니다.

취약점 대상은 kube-proxy에 국한되지 않습니다. 공격자가 제어하는 이미지와 레이어를 공유하는 모든 권한 있는 DaemonSet(모니터링 에이전트, CNI 플러그인, 로그 수집기, 보안 에이전트 등)이 실행 가능한 대상입니다.

Copy Fail과의 차이점

이 프로젝트는 Copy Fail Kubernetes PoC에 문서화된 Kubernetes 악용 모델에서 영감을 얻었지만, 다른 커널 프리미티브를 사용합니다.

속성	Copy Fail	Dirty Frag
CVE	CVE-2026-31431	CVE-2026-43284
커널 경로	`AF_ALG` + `splice()`	`xfrm/ESP` + `splice()`
네임스페이스 요구 사항	필요 없음	사용자 네임스페이스 필요
사용되는 주요 capability	초기 컨테이너에서 없음	새 네트 네임스페이스 내 `CAP_NET_ADMIN`
관련 모듈	`algif_aead`	`esp4`
실질적 차이점	AF_ALG 벡터가 차단되면 실패	AF_ALG를 사용할 수 없지만 ESP/사용자 네임스페이스가 활성화된 경우에도 유효

작동 방식

공격 체인은 세 단계로 구성됩니다: 페이지 캐시 손상, 컨테이너 간 전파, 권한 있는 실행.

1. xfrm/ESP를 통한 페이지 캐시 패치

PoC 바이너리는 비특권 컨테이너에서 다음 순서를 수행합니다:

unshare(CLONE_NEWUSER | CLONE_NEWNET)로 새 사용자 및 네트 네임스페이스에 진입합니다.
높은 시퀀스 필드가 4바이트 페이로드 청크를 인코딩하는 많은 xfrm 보안 연관(Security Association)을 등록합니다.
공유 이미지 레이어에서 대상 바이너리를 읽기 전용으로 엽니다.
splice()와 조작된 ESP 입력을 사용하여 취약한 커널 경로를 트리거합니다.
대상 바이너리의 페이지 캐시 내용에 포함된 페이로드가 포함될 때까지 프리미티브를 반복합니다.

대상 파일에 대한 쓰기 권한은 필요하지 않습니다. 디스크의 파일은 변경되지 않습니다 — 메모리 내 페이지 캐시만 손상됩니다.

2. 공유 레이어를 통한 컨테이너 간 전파

컨테이너 런타임은 커널 페이지 캐시를 통해 overlay 하위 레이어에서 읽기를 제공합니다. PoC 컨테이너와 kube-proxy가 동일한 하위 레이어 파일을 공유하면 둘 다 동일한 캐시된 페이지를 관찰합니다.

이 저장소의 EKS 이미지는 다음에서 빌드됩니다:

public.ecr.aws/eks-distro-build-tooling/eks-distro-minimal-base-iptables:2026-03-11-1773190710.2023

이 베이스는 검증된 환경에서 사용된 EKS kube-proxy 사용자 공간 도구 체인 레이어와 일치하도록 선택되었습니다.

3. kube-proxy에 의한 권한 있는 실행

kube-proxy가 다음에 패치된 iptables 계열 바이너리를 실행하면 커널이 손상된 캐시된 페이지를 로드합니다. PoC 페이로드는 호스트 루트 디바이스를 마운트하고 /root/res에 마커 파일을 기록합니다.

예상 마커 내용은 다음과 같습니다:

[*] success

공격 흐름 다이어그램

┌──────────────────────────────┐     ┌────────────────────────┐     ┌──────────────────────────┐
│  PoC Pod                     │     │  커널 페이지 캐시       │     │  kube-proxy DaemonSet    │
│  비특권 컨테이너              │     │                        │     │  권한 있는 컨테이너       │
│                              │     │                        │     │                          │
│  1. unshare user+net ns      │     │                        │     │                          │
│  2. xfrm SA 설치             │     │                        │     │                          │
│  3. ESP 경로를 통해           │────▶│  공유 레이어 바이너리    │────▶│  패치된 바이너리 실행     │
│     대상 바이너리 splice      │     │  페이지 캐시 패치됨     │     │  페이로드가 노드 수준     │
│                              │     │                        │     │  권한으로 실행됨          │
└──────────────────────────────┘     └────────────────────────┘     └──────────────────────────┘

검증된 환경

Amazon EKS

속성	값
플랫폼	Amazon Elastic Kubernetes Service (EKS)
노드 커널	`6.12.80-106.156.amzn2023.x86_64`
패치 상태	수정 전 커널, `f4c50a4034e6` 누락
`esp4` 모듈	로드됨
사용자 네임스페이스	활성화됨 (`user.max_user_namespaces=15030`)
SELinux	Permissive
Seccomp	테스트된 Pod 컨텍스트에서 Unconfined
대상 DaemonSet	`kube-proxy`
대상 권한	`privileged: true`, `hostNetwork: true`
프록시 모드	iptables
마커 경로	`/root/res`

GKE 및 ACK — 테스트됨, 기본 구성으로 악용 불가

GKE 및 ACK 클러스터에서 테스트했습니다. 모두 실패했습니다.

플랫폼	결과	이유
Alibaba Cloud ACK	실패	`user.max_user_namespaces`가 기본 노드 이미지에서 `0`으로 설정되어 있어 비특권 사용자가 `CLONE_NEWUSER` unshare를 사용할 수 없습니다.
Google GKE	실패	`user.max_user_namespaces`는 `15426`이지만 kubelet이 `--seccomp-default`를 활성화합니다. 기본 seccomp 정책이 `unshare` syscall을 비활성화합니다.

Dirty Frag 프리미티브는 새 네트 네임스페이스 내에서 CAP_NET_ADMIN을 얻기 위해 사용자 네임스페이스 생성(CLONE_NEWUSER)이 필요합니다. ACK와 GKE 모두 서로 다른 메커니즘으로 노드 수준에서 이를 차단합니다:

ACK: 커널 수준 제한(user.max_user_namespaces=0)이 비특권 사용자 네임스페이스 생성을 완전히 차단합니다.
GKE: seccomp 기본 프로필(kubelet의 --seccomp-default 플래그로 활성화)이 네임스페이스 제한과 관계없이 unshare syscall을 차단합니다.

이는 사용자 네임스페이스가 필요하지 않고 세 플랫폼 모두에서 성공적으로 악용되는 Copy Fail (CVE-2026-31431)과의 주요 차이점입니다.

kube-proxy를 구체적인 예로

제공된 EKS 변형은 다음 바이너리가 존재할 때 패치합니다:

/usr/sbin/xtables-legacy-multi
/usr/sbin/xtables-nft-multi

이 바이너리는 kube-proxy가 사용하는 iptables 도구 체인에 의해 호출됩니다. 정확한 트리거 시점은 노드 및 서비스 조정 활동에 따라 달라집니다. 검증된 환경에서 페이로드는 일반적인 kube-proxy 조정에 의해 트리거되었습니다.

중요한 주의 사항:

kube-proxy는 ipvs 모드로 구성된 경우에만 ipset을 호출합니다. 기본 모드(iptables)는 ipset을 사용하지 않습니다.
일부 관리형 Kubernetes 배포판은 kube-proxy를 비특권 컨테이너로 실행하여 탈출의 영향을 제한합니다.
PoC는 여러 바이너리(xtables-legacy-multi, xtables-nft-multi)를 대상으로 하여 다양한 프록시 모드를 포괄하지만, 호출 여부는 클러스터 구성에 따라 달라집니다.

Dirty-Frag-Kubernetes-PoC

인기