Skip to content

Latest commit

 

History

History
292 lines (228 loc) · 14.9 KB

File metadata and controls

292 lines (228 loc) · 14.9 KB

Windows Hyper-V CrossVmEvent heap overflow privilege escalation (CVE-2025-21333)

메타데이터

항목 내용
CVE ID CVE-2025-21333
영향 제품 Windows Hyper-V NT Kernel Integration VSP
취약점 유형 Heap-based Buffer Overflow, 권한 상승
CVSS v3.1 7.8 High - AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
공개일 2025-01-14
CISA KEV 2025-01-14 등재, 2025-02-04 조치 기한
확인된 CWE CWE-122: Heap-based Buffer Overflow
분석 기준 Microsoft/NVD/CISA 공개 메타데이터, Exploit-DB 공개 PoC의 정적 코드 흐름, Hyper-V 공개 아키텍처 문서

개요

CVE-2025-21333은 Windows Hyper-V NT Kernel Integration VSP에서 발생한 로컬 권한 상승 취약점이다. Microsoft와 NVD는 이 취약점을 Hyper-V NT Kernel Integration VSP의 권한 상승으로 분류했고, CWE-122 heap-based buffer overflow 및 PR:L 로컬 공격 조건을 부여했다. CISA는 공개 당일 이 취약점을 KEV에 추가했으며, 공개 exploit 자료도 존재한다.

이 취약점의 학습 포인트는 Hyper-V가 "가상 머신 기능"으로 보이지만 실제로는 호스트 Windows 커널, 사용자 모드 관리 프로세스, VMBus/VSP/VSC, Windows 객체/핸들 모델이 함께 움직인다는 점이다. 공개 PoC는 Windows Sandbox/Hyper-V 세션에서 CrossVmEvent를 만들고, WNF 객체와 I/O ring을 이용해 커널 풀 배치를 조작한 뒤, overflow 이후 손상된 커널 객체를 읽기/쓰기 primitive로 연결하려는 흐름을 보인다. 단, Microsoft는 취약 함수나 패치 diff를 공개하지 않았으므로, 본문은 확인된 사실과 공개 PoC에서 추론 가능한 동작을 분리한다.

사전 지식

Hyper-V는 하이퍼바이저 하나가 아니라 파티션과 서비스 계층의 조합이다

Hyper-V는 type-1 hypervisor로 하드웨어 위에서 동작하지만, VM의 모든 입출력을 하이퍼바이저가 직접 처리하지는 않는다. Microsoft의 Hyper-V 개요는 Hyper-V가 Windows Server/Windows에 내장된 하드웨어 가상화 기술이며, VM 격리와 관리 기능을 제공한다고 설명한다. 실제 장치 접근은 대체로 루트/부모 파티션의 Windows 구성요소가 맡는다.

개념적으로 보면 다음과 같다.

물리 하드웨어
    │
    ▼
Hyper-V hypervisor
    │
    ├─ Parent/root partition: 호스트 Windows
    │      ├─ VM 관리 프로세스
    │      ├─ VSP(Virtualization Service Provider)
    │      └─ 커널 드라이버/장치 스택
    │
    └─ Child partition: 게스트 VM 또는 Sandbox
           └─ VSC(Virtualization Service Client)

VSC는 게스트 쪽 드라이버이고, VSP는 호스트 쪽 서비스 제공자다. 게스트가 합성 장치(synthetic device)에 접근하면 요청은 VMBus 같은 파티션 간 통신 채널을 통해 호스트의 VSP로 간다. 성능을 위해 에뮬레이션을 줄이고 직접 메시지/공유 메모리 모델을 쓰기 때문에, VSP는 "외부 입력을 받는 커널 경계"처럼 다뤄야 한다. VM 내부나 sandbox 관련 프로세스가 만든 요청이라고 해서 안전한 입력이라는 뜻은 아니다.

Cross-VM event는 동기화 객체처럼 보이지만 보안 경계를 지난다

공개 PoC는 ntdll.dll에서 NtCreateCrossVmEvent를 찾아 호출한다. 함수 이름과 인자 흐름만 놓고 보면 이는 VM/호스트 또는 VM 관련 컴포넌트 사이에서 이벤트 객체를 공유하기 위한 NT 계열 시스템 서비스로 해석된다. 공개 문서화가 충분하지 않으므로 내부 구조를 단정할 수는 없지만, PoC는 Windows Sandbox 클라이언트 프로세스의 명령줄에서 GUID를 추출하고 그 GUID를 NtCreateCrossVmEvent 호출에 넣는다.

이 모델에서 중요한 것은 이벤트 자체보다 "이벤트를 식별하고 연결하는 메타데이터"다.

WindowsSandboxClient.exe
        │  세션/VM 식별 GUID
        ▼
NtCreateCrossVmEvent(...)
        │  ObjectAttributes, DesiredAccess, GUID
        ▼
Hyper-V / NT kernel integration path
        │
        ▼
커널 객체 생성 또는 기존 cross-VM 이벤트 연결

일반 NT 객체 생성 API처럼 보이더라도, 인자에는 OBJECT_ATTRIBUTES, 보안 설명자, 이름/식별자, 권한 마스크가 섞인다. 이 값들이 커널 풀에 복사되거나 내부 객체 구조로 변환될 때 길이 계산과 버퍼 크기 검증이 정확해야 한다. CVE-2025-21333의 CWE가 heap-based buffer overflow라는 점은 이 변환 경계에서 고정 크기 또는 잘못 계산된 heap 버퍼보다 많은 데이터가 쓰였을 가능성을 시사한다. 이는 공개 근거에서의 추론이며, Microsoft가 취약 루틴을 공개한 것은 아니다.

Windows 커널 풀 overflow는 "쓰기 한 번"보다 주변 객체 배치가 더 중요하다

커널 heap overflow는 사용자 모드 버퍼 overflow와 다르게, 성공 여부가 주변 커널 객체의 배치에 크게 좌우된다. 공격자는 단순히 overflow를 발생시키는 데서 끝나지 않고, overflow 대상 버퍼 바로 뒤에 공격자가 의미 있게 해석할 수 있는 객체가 놓이도록 heap feng shui를 수행한다.

공개 PoC는 이 목적에 WNF(Windows Notification Facility) state name/data와 I/O ring 관련 객체를 사용한다. WNF는 Windows 내부에서 상태 변경 알림을 배포하기 위한 커널 지원 메커니즘이고, I/O ring은 Windows의 비동기 I/O 제출/완료 큐 모델이다. 두 기능 모두 정상 기능이지만, 커널 풀 객체를 많이 만들고 지우며 크기와 위치를 조절하는 데 악용될 수 있다.

커널 풀 배치의 단순 모델

1. spray: 같은 크기의 WNF 데이터 객체를 많이 만든다

   [WNF][WNF][WNF][WNF][WNF][WNF]

2. holes: 일부 객체를 해제해 빈 공간을 만든다

   [WNF][free][WNF][free][WNF][free]

3. trigger: 취약 객체가 빈 공간에 배치되고 overflow가 이웃 객체를 덮는다

   [WNF][CrossVmEvent buffer -> overflow][corrupted WNF]

이런 기법은 취약점의 본질이 아니라 exploit 안정화 단계다. 보고서에서 구분해야 할 점은, 취약점 자체는 Hyper-V/NT kernel integration 경로의 heap overflow이고, WNF/I/O ring은 overflow 이후 손상을 관찰하고 커널 읽기/쓰기 primitive로 확장하기 위한 공개 PoC의 선택이라는 점이다.

취약점 분석

확인된 사실

Microsoft/NVD 기준으로 CVE-2025-21333은 Windows Hyper-V NT Kernel Integration VSP의 권한 상승 취약점이다. NVD는 Microsoft가 제공한 CVSS v3.1 벡터를 AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H로 표시한다. 이는 공격자가 로컬에서 낮은 권한을 가지고 있어야 하지만, 사용자 상호작용 없이 기밀성/무결성/가용성에 높은 영향을 줄 수 있다는 뜻이다. NVD의 변경 이력은 Microsoft가 CWE-122를 제공했음을 보여 주며, CISA KEV는 이 취약점을 "Microsoft Windows Hyper-V NT Kernel Integration VSP Heap-based Buffer Overflow Vulnerability"로 등재했다.

Exploit-DB에는 2025-09-16 등록된 Windows local exploit 항목이 있으며, 코드에는 NtCreateCrossVmEvent, WindowsSandboxClient.exe, WNF state spray, I/O ring 구조체, 커널 토큰 관련 오프셋 등이 등장한다. 이 코드는 실행하지 않았고, 원 취약점과 후속 권한 상승 primitive를 구분하기 위한 정적 참고 자료로만 보았다.

취약점 동작 원리

패치 전 흐름은 다음과 같은 형태로 추론할 수 있다.

패치 전 추정 흐름

[1] 낮은 권한 로컬 프로세스
    Windows Sandbox/Hyper-V 관련 세션을 준비하고 세션 GUID를 얻음

[2] 커널 풀 grooming
    WNF state data를 대량 생성/삭제해 특정 크기 객체 주변에 빈 공간을 만듦

[3] 취약 API 호출
    NtCreateCrossVmEvent(ObjectAttributes, ..., GuidA, GuidB)

[4] Hyper-V NT kernel integration VSP 경로
    cross-VM event 생성/연결용 메타데이터를 커널 heap 버퍼에 구성

[5] 길이 또는 경계 검증 실패
    내부 heap 버퍼 범위를 넘어 인접 pool 객체 일부를 덮음

[6] 손상된 객체 재해석
    WNF/I/O ring 등 후속 primitive로 커널 읽기/쓰기 또는 토큰 조작을 시도

[7] 결과
    낮은 권한 로컬 코드가 높은 권한 커널/시스템 권한으로 상승 가능

여기서 핵심 불변식은 "cross-VM event 생성 경로가 외부에서 온 모든 식별자와 속성을 내부 버퍼 크기에 맞게 검증해야 한다"이다. VSP는 게스트/샌드박스/관리 프로세스와 호스트 커널 사이의 중간 계층이므로, 입력이 로컬 API 호출 형태를 띠더라도 신뢰할 수 없다. 특히 이벤트 식별자, 보안 속성, 객체 이름, GUID 같은 값은 내부 표현으로 변환되며, 변환 후 크기가 원래 예상보다 커질 수 있다.

취약한 경계의 정신 모델

user-controlled-ish metadata
  ├─ OBJECT_ATTRIBUTES
  ├─ security descriptor / access mask
  └─ VM 또는 세션 GUID
          │
          ▼
   [크기 계산]  ── 불충분하면 ──┐
          │                     │
          ▼                     ▼
   kernel heap buffer      adjacent pool object
   [ expected bytes ] [ overwritten bytes ... ]

공개 PoC가 NtCreateCrossVmEvent 호출 직전에 WNF 객체를 spray하고, 호출 직후 추가 WNF 객체를 만든 다음 손상된 WNF 데이터를 찾는 구조라는 점은 overflow가 커널 풀의 이웃 객체에 영향을 준다는 해석과 맞다. 다만 실제 취약 함수가 어떤 필드를 몇 바이트 잘못 복사했는지, 패치가 어느 함수에 어떤 조건문을 추가했는지는 공개 Microsoft 소스 또는 신뢰 가능한 binary diff가 없어 확인하지 못했다.

왜 Hyper-V 취약점이 호스트 권한 상승으로 이어지는가

Hyper-V 계층은 VM 격리를 제공하지만, 그 격리를 구현하는 상당 부분은 호스트 Windows의 커널과 루트 파티션 서비스가 담당한다. VSP가 호스트 커널 권한으로 동작하는 경로에서 메모리 손상이 발생하면, 공격자가 얻는 것은 단순한 VM 내부 crash가 아니라 호스트 커널 객체 손상이다.

권한 경계

낮은 권한 사용자 프로세스
        │
        │ syscall / NT API
        ▼
호스트 Windows 커널
        │
        │ Hyper-V integration / VSP 처리
        ▼
커널 pool 객체 손상
        │
        ▼
토큰/핸들/I/O primitive로 연결되면 SYSTEM 또는 커널 수준 영향

CVSS의 S:U는 보안 범위(scope)가 바뀌지 않는다는 뜻이다. 즉 이는 게스트에서 다른 보안 권한 영역으로 넘어가는 원격 VM escape로 공식 분류된 것이 아니라, 같은 Windows 시스템 안에서 낮은 권한 로컬 공격자가 더 높은 권한을 얻는 취약점으로 이해하는 편이 안전하다. 공개 PoC가 Windows Sandbox 클라이언트를 활용한다고 해서 모든 세부 조건이 일반 Hyper-V VM escape와 같다고 단정해서는 안 된다.

수정 방법

Microsoft는 2025년 1월 보안 업데이트에서 영향을 받는 Windows 버전의 수정 빌드를 제공했다. NVD 변경 이력에는 예를 들어 Windows 10 21H2는 10.0.19044.5371 미만, Windows 10 22H2는 10.0.19045.5371 미만, Windows 11 22H2는 10.0.22621.4751 미만, Windows 11 24H2 및 Windows Server 2025 계열은 10.0.26100.2894 미만 빌드가 영향 범위로 표시된다. 실제 적용 여부는 Microsoft Security Update Guide와 조직의 Windows Update/WSUS/Intune 기준으로 확인해야 한다.

패치의 내부 diff는 공개되어 있지 않다. 따라서 수정 방향은 다음처럼 추정할 수만 있다.

패치 후 기대 흐름

NtCreateCrossVmEvent(...)
        │
        ▼
입력 GUID/객체 속성/보안 메타데이터 검증
        │
        ├─ 길이/형식/상태가 유효하지 않음 ──> 오류 반환
        │
        └─ 유효함
              │
              ▼
        정확한 크기의 kernel buffer 할당
              │
              ▼
        경계 안에서만 복사/초기화
              │
              ▼
        cross-VM event 생성 또는 연결

운영 관점의 우선순위는 단순하다.

  1. Hyper-V, Windows Sandbox, VBS/가상화 기반 기능을 사용하는 Windows 클라이언트/서버에 2025년 1월 이후 누적 보안 업데이트를 적용한다.
  2. CISA KEV 등재 취약점이므로, 패치 예외 시스템은 별도 위험 승인과 보완 통제를 둔다.
  3. 로컬 권한 상승 취약점이므로 EDR 경보에서는 WindowsSandbox.exe, WindowsSandboxClient.exe, 대량 WNF state 조작, 비정상적인 I/O ring 사용, 짧은 시간의 커널 객체 spray 패턴을 함께 본다. 이는 탐지 아이디어이지, Microsoft가 제공한 공식 IOC는 아니다.

PoC 관련 언급

Exploit-DB의 공개 exploit 코드는 정적 분석 참고로만 확인했다. 이 코드는 NtCreateCrossVmEvent 호출을 취약점 트리거로 표시하고, WNF state spray와 I/O ring 구조체를 이용해 손상된 커널 객체를 권한 상승 primitive로 바꾸려는 흐름을 포함한다. 실행, 컴파일, 재현은 수행하지 않았다.

이 PoC는 원 취약점의 트리거, heap grooming, 후속 커널 읽기/쓰기, 토큰 조작 아이디어가 한 파일에 섞여 있다. 따라서 보고서에서는 "CVE-2025-21333의 원인은 Hyper-V NT Kernel Integration VSP의 heap overflow"까지만 확인된 공식 사실로 두고, NtCreateCrossVmEvent 및 WNF/I/O ring 세부 흐름은 공개 PoC를 근거로 한 추론으로 취급한다.

미해결/불확실 지점

  • Microsoft는 취약 함수, 정확한 overflow 필드, 패치 diff를 공개하지 않았다.
  • 공개 exploit은 유용한 정적 단서지만, Exploit-DB 항목만으로는 Microsoft 패치 전후의 정확한 코드 차이를 검증할 수 없다.
  • NtCreateCrossVmEvent는 공개 문서화가 제한적이므로, 함수의 안정적인 ABI와 내부 구조는 Windows 빌드별로 달라질 수 있다.
  • Windows Sandbox를 이용한 공개 PoC 흐름이 모든 Hyper-V 구성에서 동일한 전제 조건을 갖는지는 별도 검증이 필요하다.

참고 자료