1. 취약점 설명
Linux KVM 하이퍼바이저의 shadow MMU 코드에 2010년부터 16년간 숨어있던 Use-After-Free 취약점. 게스트 VM 안에서 호스트 커널 메모리를 손상시켜 호스트 전체를 장악할 수 있다. Intel과 AMD x86 모두 영향을 받으며, 공개된 PoC만으로도 호스트 커널 패닉(DoS)이 발생한다. 완전한 게스트-호스트 탈출 익스플로잇은 미공개 상태지만 연구자가 보유 중이라고 밝혔다.
2. 취약점 개요
| 항목 | 내용 |
| CVE 번호 | CVE-2026-53359 |
| 별칭 | Januscape |
| CVSS | 미할당 (Critical 수준으로 평가) |
| CWE | CWE-416 (Use After Free) |
| 발표일 | 2026년 7월 6일 |
| 영향 제품 | Linux Kernel KVM (x86, Intel/AMD) |
| 취약 버전 | 커밋 2032a93d66fa (2010.08) ~ 81ccda30b4e8 (2026.06) |
| 패치 버전 | 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211, 5.10.260 |
| 발견자 | Hyunwoo Kim (@v4bel), Google kvmCTF 제출 |
Use-After-Free(UAF)란?
프로그램이 메모리를 해제(free)한 후에도 해당 주소를 계속 참조(use)하는 취약점. 해제된 메모리에 공격자가 원하는 데이터를 심으면 프로그램 실행 흐름을 조작할 수 있다.
KVM이란?
Linux 커널에 내장된 하이퍼바이저. AWS, GCP 같은 클라우드 환경에서 VM을 실행하는 데 사용된다. KVM 위에서 여러 VM이 동시에 실행되며 서로 격리되어 있어야 하는데, 이 격리가 이번 취약점으로 무너진다.
호스트 vs 게스트:
호스트 = 실제 물리 서버 (진짜 하드웨어가 있는 컴퓨터)
게스트 = 호스트 위에서 실행되는 가상 컴퓨터(VM)
AWS에서 EC2 인스턴스를 임대하면 데이터센터 물리 서버가 호스트이고 우리가 쓰는 인스턴스가 게스트다. 하나의 호스트 위에 여러 게스트가 동시에 실행되며 원래는 서로 접근이 불가능해야 한다. 이 취약점은 게스트에서 호스트로 탈출하는 것이 핵심이다.
3. 익스플로잇 방식
shadow MMU가 뭔지
KVM이 VM을 실행할 때 게스트의 메모리 주소를 호스트 실제 메모리 주소로 변환해야 한다. Intel EPT나 AMD NPT 같은 하드웨어 지원이 있으면 CPU가 직접 처리하지만, 중첩 가상화(nested virtualization)가 켜지는 순간 KVM이 소프트웨어로 직접 shadow page table을 관리한다. 이 코드가 취약점의 무대다.
EPT / NPT란?
EPT(Extended Page Table) = Intel CPU 내장 기능, NPT(Nested Page Table) = AMD CPU 내장 기능. 둘 다 같은 역할로, 게스트 메모리 주소를 호스트 실제 메모리 주소로 변환하는 작업을 CPU가 하드웨어 레벨에서 처리해준다. 이름만 다르고 하는 일은 동일하다.
중첩 가상화(nested virtualization)란?
VM 안에서 또 VM을 실행하는 것. 클라우드에서 가상화 테스트 환경을 구성하거나 클라우드 서비스 자체를 구축할 때 필요하다. 중첩 가상화가 켜지는 순간 하드웨어(EPT/NPT)만으로는 주소 변환이 불가능해서 KVM이 소프트웨어로 직접 shadow page table을 관리해야 하는데, 이 코드 안에 취약점이 있다.
GFN vs role:
GFN(Guest Frame Number) = 게스트 메모리 페이지 번호. 메모리를 4KB 단위로 나눠 관리할 때 각 페이지의 번호표. role = shadow page가 어떤 용도인지 나타내는 속성값. 같은 GFN이라도 role이 다르면 완전히 다른 용도의 shadow page다. 취약한 코드는 GFN만 같으면 재사용했고, 패치 후에는 GFN과 role 둘 다 일치해야 재사용하도록 수정됐다.
공격 흐름:
1. 공격자가 클라우드에서 VM 인스턴스 하나를 임대
(기본적으로 VM 안에서 root 권한 보유)
2. 호스트에서 중첩 가상화가 활성화된 것을 확인
3. 게스트 안에서 PDE(Page Directory Entry) 매핑을 조작
→ KVM이 shadow page를 재사용할 때
GFN(guest frame number)만 비교하고 role을 비교하지 않는 버그 트리거
4. KVM이 이미 해제된 kvm_mmu_page 구조체를 계속 참조
→ Use-After-Free 발생
5. 해제된 메모리에 대한 접근으로 호스트 커널 메모리 손상
→ 호스트 커널 패닉(DoS) 또는 호스트에서 root 권한 코드 실행(RCE)왜 취약하냐면:
// 취약한 코드 (kvm_mmu_get_child_sp())
// GFN만 비교하고 role은 확인하지 않음
if (sp->gfn == gfn)
return sp; // role이 달라도 그냥 재사용
// 패치 후 (단 한 줄 추가)
if (sp->gfn == gfn && sp->role.word == role.word)
return sp; // GFN + role 모두 일치해야 재사용16년간 존재했던 취약점이 단 한 줄의 조건 추가로 패치됐다.
이 취약점이 특히 위험한 이유:
공개 클라우드에서 VM을 임대하면 기본적으로 VM 안에서 root 권한을 갖는다. 중첩 가상화가 허용된 환경이면 추가 권한 없이 바로 공격이 가능하다. VM 하나를 임대해서 같은 물리 서버에 올라간 다른 모든 VM을 다운시키거나 탈취할 수 있는 셈이다.
4. 어디서 흔적이 남는가 (로그 소스 매핑)
이 취약점은 하이퍼바이저 커널 내부에서 발생하기 때문에 탐지가 매우 어렵다. 직접적인 공격 흔적보다 공격 전후 행위 패턴을 탐지하는 접근이 현실적이다.
| 로그 소스 | 탐지 가능한 흔적 |
| Linux 커널 로그 (syslog/dmesg) | KVM 관련 커널 패닉, BUG/WARN 메시지 |
| auditd 로그 | /dev/kvm 접근, 중첩 가상화 관련 ioctl 호출 |
| VM 관리 로그 (libvirt, QEMU) | 비정상적인 VM 생성/종료 패턴 |
| 호스트 시스템 로그 | 비정상적인 권한 상승, 프로세스 생성 |
| 네트워크 로그 | VM 탈출 후 호스트에서 비정상 아웃바운드 연결 |
⚠️ 탐지의 핵심 어려움
공격이 커널 메모리 수준에서 발생하기 때문에 EDR이나 일반 로그로는 공격 자체를 직접 탐지하기 어렵다. 커널 패닉 발생 여부, /dev/kvm 비정상 접근, 중첩 가상화 활성화 여부를 모니터링하는 것이 현실적인 접근이다.
5. SPL 탐지 쿼리
기본형: /dev/kvm 비정상 접근 탐지
index=linux_audit OR index=syslog
| search (path="/dev/kvm" OR syscall="ioctl")
| where user!="root" AND user!="libvirt-qemu"
| stats count as access_count by user, src_host, path
| where access_count > 5
| sort -access_count쿼리 설명:
- /dev/kvm은 root 또는 가상화 관련 계정만 접근해야 정상이다
- 일반 사용자가 /dev/kvm에 접근하거나 ioctl을 호출하면 로컬 권한 상승 시도로 볼 수 있다
- user!="root" AND user!="libvirt-qemu" 로 정상 접근을 걸러내고 비정상만 추출
왜 root를 제외하는데 권한 상승이 나오냐면:
이 취약점의 공격 경로는 두 가지다. 첫 번째는 VM 안에서 호스트를 탈출하는 경로로, VM을 임대하면 기본으로 root 권한이 있어서 권한 상승이 필요 없다. 두 번째는 호스트에 일반 유저로 접근한 공격자가 /dev/kvm을 직접 열어 취약점을 트리거하는 로컬 권한 상승 경로다. 기본형 쿼리는 이 두 번째 경로를 탐지하는 것이고, 첫 번째 경로(게스트→호스트 탈출)는 개선형 쿼리(커널 오류 + 의심 프로세스 연계)로 탐지한다.
syscall이란?
프로그램이 OS 커널에게 작업을 요청하는 인터페이스. 파일 읽기, 프로세스 생성, 네트워크 연결 같은 작업은 반드시 커널을 통해야 하고, 이 요청이 syscall이다. auditd는 이 syscall 호출을 기록하기 때문에 공격자가 호스트에서 어떤 프로세스를 실행했는지 추적할 수 있다.
exe 필드란?
auditd 로그에서 실행된 프로그램의 전체 경로를 담는 필드. 예: exe="/bin/bash". 환경마다 필드명이 다를 수 있으므로 실제 적용 전 자사 auditd 로그의 필드명을 먼저 확인해야 한다.
⚠️ 주의: RHEL 계열에서는 기본적으로 /dev/kvm이 0666(누구나 접근 가능)으로 설정되어 있어 오탐이 많을 수 있다. 자사 환경의 /dev/kvm 권한 설정을 먼저 확인할 것.
개선형: 커널 KVM 오류 발생 + 이후 비정상 프로세스 연계 탐지
index=syslog OR index=linux_logs
| search ("kernel: BUG" OR "kernel: WARNING" OR "kvm_mmu" OR "use-after-free" OR "pte_list")
| eval suspicious=if(match(_raw, "(kvm_mmu|shadow|sptep|rmap|pte_list)"), 1, 0)
| where suspicious=1
| stats count as kvm_error_count by host, _time span=10m
| where kvm_error_count > 3
| join type=left host
[search index=linux_audit
| where syscall IN ("execve", "fork", "clone")
| eval suspicious_proc=if(match(exe, "(bash|sh|python|perl|nc|ncat)"), 1, 0)
| where suspicious_proc=1
| stats count as suspicious_proc_count by host]
| where isnotnull(suspicious_proc_count)
| table host, kvm_error_count, suspicious_proc_count쿼리 설명:
- KVM 메모리 관련 커널 오류(BUG, WARNING, kvm_mmu 등)가 발생한 호스트를 1차 필터링
- 해당 호스트에서 이후 의심 프로세스(bash, nc 등)가 실행되면 VM 탈출 후 공격자가 호스트에서 명령을 실행하는 패턴으로 볼 수 있다
join으로 커널 오류 로그와 audit 로그를 연계해 공격 전후 흐름을 한번에 포착
⚠️ 인덱스명 안내: syslog, linux_audit, linux_logs 는 예시다. 실제 환경의 인덱스명으로 변경 후 사용할 것. 확인 방법: Splunk 검색창에 | eventcount summarize=false 입력.
중첩 가상화 활성화 여부 확인
index=linux_logs OR index=syslog
| search ("kvm_intel" OR "kvm_amd")
| search ("nested=1" OR "nested_virtualization" OR "vmx=1")
| stats count by host, _raw
| table host, _raw쿼리 설명:
- 호스트에서 중첩 가상화가 활성화된 경우를 탐지한다
- 중첩 가상화가 불필요한 환경에서 이 옵션이 켜져 있다면 즉시 비활성화를 권고한다
- 이 쿼리는 공격 탐지보다는 취약한 환경인지 파악하는 용도로 활용하는 게 맞다
6. 오탐지 줄이는 팁
- /dev/kvm 권한 확인: RHEL, CentOS 계열은 기본적으로 /dev/kvm이 누구나 접근 가능(0666)하게 설정되어 있어 오탐이 많다. 화이트리스트를 정교하게 관리하거나 권한 자체를 0660으로 변경하는 게 근본적인 해결책
- KVM 관련 커널 오류: 가상화 환경에서 KVM 관련 로그는 정상적으로도 발생할 수 있다. 임계값을 환경에 맞게 조정하고 평소 베이스라인을 잡아두는 게 중요
- 의심 프로세스: bash, sh는 일반 운영에서도 자주 실행된다. KVM 오류 발생 직후(10분 이내) 실행된 경우로 시간 조건을 좁혀야 오탐을 줄일 수 있다
7. 임시 대응 / 패치 정보
패치 적용:
| 커널 버전 | 패치 적용 버전 |
| 6.1.x | 6.1.177 이상 |
| 6.6.x | 6.6.144 이상 |
| 6.12.x | 6.12.95 이상 |
| 6.18.x | 6.18.38 이상 |
| 7.1.x | 7.1.3 이상 |
즉시 적용 가능한 완화 조치:
1. 중첩 가상화 비활성화 (패치 전 가장 효과적인 완화)
# Intel
modprobe kvm_intel nested=0
# AMD
modprobe kvm_amd nested=0
2. /dev/kvm 권한 강화 (로컬 권한 상승 경로 차단)
chmod 0660 /dev/kvm
chown root:kvm /dev/kvm
3. 신뢰할 수 없는 게스트 VM 실행 제한 (패치 배포 전까지)
⚠️ 배포판별 패치 확인 방법: 업스트림 커널 버전만으로 패치 여부를 판단하면 안 된다. 배포판마다 백포트 버전이 다르므로 자사 배포판의 보안 트래커에서 직접 확인해야 한다.
- Debian: DSA-6381-1 (7월 5일 패치 완료)
- Ubuntu: ubuntu.com/security/CVE-2026-53359 확인
- RHEL/CentOS: Red Hat CVE 페이지에서 RHSA 확인
8. 마무리 / 한계점
이 SPL 쿼리의 한계:
- 공격이 커널 메모리 수준에서 발생해 직접 탐지가 불가능하고 간접 지표만 탐지 가능
- 커널 패닉이 발생하면 로그 자체가 유실될 수 있어 사후 분석이 어려움
- 완전한 VM 탈출 익스플로잇이 아직 미공개 상태라 실제 공격 패턴이 불확실
이 취약점이 16년간 발견되지 않은 이유는 하드웨어 가속(EPT/NPT)이 기본값이 되면서 shadow MMU 코드가 거의 실행되지 않았기 때문이다. 중첩 가상화가 활성화될 때만 실행되는 레거시 코드 경로는 보안 감사에서 놓치기 쉽다. 기본값이 아닌 코드 경로도 철저히 감사해야 한다는 점을 다시 한번 상기시켜주는 취약점이다.
더 나은 탐지 방법이나 실제 운영 환경에서의 개선점이 있다면 댓글로 공유해주세요.
참고 자료: