KVM 탈출 3부작

ITScape
_{(CVE‑2026‑46316)}

Januscape
_{(CVE‑2026‑53359)}

Zapscape
_{(CVE‑2026‑64561)}

Zapscape: KVM/x86에서 게스트에서 호스트로의 탈출

tux

개요

demo

이 문서는 Hyunwoo Kim (@v4bel)이 발견하고 보고한 Zapscape (CVE-2026-64561) 취약점에 대해 설명합니다. 이 취약점은 KVM/x86 환경에서 게스트가 호스트로 탈출하여 호스트에서 커널(root) 권한으로 명령을 실행할 수 있게 하는 KVM 탈출 취약점입니다.

Zapscape는 KVM/x86의 shadow MMU 에뮬레이션에서 발생하는 use-after-free 취약점으로, 특히 shadow 페이지가 회수될 때 실행되는 재귀적 zap 경로에서 발생합니다. 게스트 측 작업만으로 버그를 트리거하여 호스트 커널의 shadow 페이지를 손상시킬 수 있으며, 신뢰할 수 없는 게스트를 수용하고 중첩 가상화를 노출하는 KVM/x86 호스트, 특히 멀티테넌트 x86 퍼블릭 클라우드의 게스트-호스트 격리를 위협할 수 있습니다.

자세한 기술 정보는 여기를 참조하세요.

[!NOTE] 이 취약점을 [email protected]에 보고한 후 합의된 엠바고가 종료되어, 익스플로잇이 oss-security에 게시되고 이 Zapscape 문서가 공개되었습니다. 공개 일정은 기술 상세 문서를 참조하세요.

PoC 구조

PoC는 AMD를 대상으로 작성되었으며, 안전한 테스트를 위해 QEMU TCG에서 실행하는 것이 권장됩니다. PoC의 구조는 다음과 같습니다.

L0: Linux 7.1.3 + KVM_AMD on an x86_64 CPU (AMD SVM/NPT) emulated by QEMU TCG. The escape target
  └─ L1: the guest poc creates. Switching long -> PAE aliases one shadow page as both child and pinned root, and L1 then escalates the UAF into L0 kernel code-exec
       └─ L2: the guest L1 VMRUNs. Its memory touches trigger L0's quota reclaim -> recursive zap with no root_count guard -> UAF

이 PoC는 클라우드 환경에서 즉시 실행되는 무기화된 익스플로잇이 아니라, QEMU TCG 위에서 취약점과 전체 익스플로잇 체인을 재현하는 데모 코드입니다. 실제 클라우드 환경에서 사용하려면 PoC가 수행하는 L1 작업을 게스트 커널 모듈로 옮기고, 호스트 커널의 kconfig에 맞게 익스플로잇을 포팅해야 합니다. 이는 어려운 작업이 아닙니다.

PoC 사용법

취약한 v7.1.3 커널 소스를 다운로드한 다음, 포함된 kconfig를 기반으로 커널 이미지를 빌드합니다.
PoC를 빌드한 다음, BusyBox 등을 사용하여 적절한 initramfs를 구성하고 빌드된 PoC를 initramfs에 넣습니다.

# gcc -O2 -g -static -pthread poc.c -o poc

다음 명령으로 Linux 7.1.3 대상을 부팅합니다. QEMU v9.2.0 이상에서 테스트하세요.

# ./qemu.sh bzImage initramfs.cpio.gz

QEMU TCG가 부팅된 후 PoC를 실행합니다. 익스플로잇에 성공하면 게스트를 탈출하여 호스트에 root 소유의 /Zapscape 파일을 생성합니다.

 /$$$$$$$$  /$$$$$$  /$$$$$$$
|_____ $$  /$$__  $$| $$__  $$
     /$$/ | $$  \ $$| $$  \ $$
    /$$/  | $$$$$$$$| $$$$$$$/
   /$$/   | $$__  $$| $$____/
  /$$/    | $$  | $$| $$
 /$$$$$$$$| $$  | $$| $$
|________/|__/  |__/|__/

[+] /Zapscape created by the target KVM host kernel (owner uid=0, mode=0644).
[+] exploit completed - verify with: ls -la /Zapscape
zapscape(uid=65534)$ ls -la /Zapscape
-rw-r--r--    1 root     root             0 Jul 29 05:27 /Zapscape
zapscape(uid=65534)$

이 PoC는 정확한 정보를 제공하기 위한 것입니다. 테스트 권한이 없는 시스템에서는 사용하지 마십시오.

영향받는 버전

Zapscape (CVE-2026-64561)는 f95eec9bed76 (2020-07-08)부터 2abd5287f083 (2026-07-21)까지의 범위를 다룹니다.

자주 묻는 질문

이 취약점의 영향은 무엇인가요?

Januscape (CVE-2026-53359)와 동일합니다:

KVM 탈출: 게스트 측 작업만으로 공격자가 자신의 VM을 실행하는 호스트를 손상시킬 수 있습니다. 예를 들어, 퍼블릭 클라우드에서 단일 인스턴스를 임대한 공격자는 호스트 커널을 패닉 상태로 만들어 동일한 물리 머신에 있는 다른 모든 테넌트 VM을 중단시키거나(DoS), 호스트에서 root 권한으로 코드를 실행하여 호스트와 그 위의 모든 게스트를 장악할 수 있습니다(RCE).
LPE: RHEL과 같은 배포판에서는 /dev/kvm이 모든 사용자에게 쓰기 권한(0666)이 있으므로, 권한 없는 사용자도 이 취약점을 LPE로 사용하여 root 권한을 얻을 수 있습니다. LPE로 사용될 때는 호스트 측 VMM ioctl을 사용할 수 있으므로 익스플로잇이 더 쉽고 안정적입니다.

이것은 Januscape와 어떤 관련이 있나요?

동일한 shadow MMU에서 발생하지만, 다른 근본 원인을 가진 별개의 취약점입니다.

그렇지만 Januscape와 달리 Intel에서는 EPT 페이지 워크 길이 4와 5가 모두 L1에 노출된 경우에만 트리거할 수 있습니다. 이는 영향 범위를 평가할 때 중요한 지점이므로 정확히 이해해야 합니다. 기술 상세 문서를 참조하세요.

이 취약점은 QEMU에서 발생하나요?

아니요. Januscape와 마찬가지로 커널 내부의 KVM에서 발생하므로 QEMU의 에뮬레이션과 무관하게 트리거됩니다. 그렇기 때문에 자체 가상화 스택을 구현하여 사용하는 대규모 퍼블릭 클라우드도 위협할 수 있습니다.

게스트 VM 내에서 root 권한이 필요한가요?

네. L1 커널 권한이 필요합니다. 퍼블릭 클라우드에서 인스턴스를 할당받으면 일반적으로 자신의 VM에서 root 권한을 가지므로 이 조건이 충족됩니다. 게스트 root가 없는 시나리오에서는 Dirty Frag와 같은 LPE와 연계해야 합니다.

KVM 취약점이 계속 나타날 것이라고 생각하나요?

네. 호스트 하이퍼바이저에 대한 지속 가능한 패치 프로세스를 구축하는 것을 권장합니다. 겨울이 다가오고 있습니다.

3부작 이후 후속작을 계획하고 있나요?

그렇지 않길 바랍니다.

Zapscape

인기