메인 콘텐츠로 건너뛰기
TilnoteAI 스퀘어

VMware Workstation PVSCSI 힙 오버플로 익스플로잇 구조 이해하기

D
dev
•조회수 15
요약

클립으로 정리됨 (생성형 AI 도구 활용)

출처 및 참고 : https://www.synacktiv.com/en/publications/on-the-clock-escaping-vmware-workstation-at-pwn2own-berlin-2025

핵심 요약

VMware Workstation의 PVSCSI 컨트롤러 힙 오버플로를 이용해, 강하게 보호된 Windows 11 LFH 위에서도 게스트에서 호스트로 탈출하는 전체 체인이 어떻게 구성되는지 설명한다.
핵심은 LFH의 동작을 정교하게 이용해 힙 레이아웃을 통제하고, URB·셰이더 객체를 결합해 정보 유출, 임의 읽기/쓰기, 임의 호출까지 이어지는 기본 요소를 만드는 과정이다.
마지막으로, 백도어 채널과 타이밍 사이드 채널을 사용해 LFH의 무작위화를 무력화하는 방법이 더해지면서, 안정적인 1-shot 익스플로잇이 완성된다.

PVSCSI 힙 오버플로 취약점의 본질

PVSCSI 컨트롤러는 게스트가 보내는 S/G(Scatter-Gather) 목록을 내부 버퍼에 복사해 사용한다.
정상 설계 의도는 항목이 많을수록 버퍼를 두 배씩 늘려가는 것이지만, 구현에서는 재할당 크기를 항상 0x4000으로 고정해 버렸다.

게스트가 512개를 넘는 S/G 항목을 보내면, 함수는 매 항목마다 0x4000 크기의 새 버퍼를 할당하고 이전 버퍼를 해제하는 재할당 루프에 들어간다.
그리고 항목 수가 1024개를 넘어가는 지점부터는 16바이트짜리 항목이 버퍼 끝을 넘어 다른 힙 청크의 메타데이터와 데이터를 덮어 쓰게 된다.

게스트가 통제하는 필드는 {addr: 64비트, length: 32비트, flags: 32비트}인데, 컨트롤러는 {addr: 64비트, length: 64비트}만 저장한다.
이때 게스트의 32비트 length는 상위 32비트가 0인 64비트로 확장되므로, 각 항목의 마지막 4바이트는 항상 0이 되어 완전한 16바이트 제어는 불가능하다.
즉, "16바이트 단위의 OOB 쓰기이지만, 그 뒤 4바이트는 강제로 0"이라는 제약을 가진 오버플로이다.

문제를 더 어렵게 만드는 점은, 취약 버퍼 크기가 0x4000으로 고정되어 Windows 11 LFH(저분산 힙) 영역에서만 할당된다는 점이다.
다른 크기를 선택해 LFH를 피하는 일반적인 우회 전략을 쓸 수 없기 때문에, LFH 안에서 승부를 봐야 했다.

Windows 11 LFH의 방어와 그 한계

LFH는 같은 크기의 청크를 버킷 단위로 관리하며, 0x4000 사이즈 클래스의 경우 버킷 하나에 16개의 요소가 들어간다.
각 청크 앞에는 16바이트 메타데이터가 붙고, 이 메타데이터에는 비밀 키 기반 체크섬이 포함된다.

청크가 할당되거나 해제될 때마다 이 체크섬이 검증되며, 값이 틀리면 즉시 프로세스가 종료된다.
따라서 메타데이터가 손상된 청크가 할당·해제되는 순간 프로그램이 죽기 때문에, 손상된 청크는 "다시는 건드리지 않도록" 힙 레이아웃을 설계해야 한다.

또한 LFH는 자유 청크를 순서대로 주지 않고, "가장 최근에 해제된 청크를 포함한 버킷"에서 "임의의 자유 청크 하나"를 골라 반환한다.
즉, 어떤 청크가 다음에 할당될지 예측하기 어렵고, 계획한 대로 힙을 쌓는 것이 매우 까다롭다.

취약 함수의 내부 동작은 다음과 비슷한 패턴으로 정리할 수 있다.

p2 = malloc(0x4000);
memcpy(p2, p1, 0x4000);
free(p1);                        // 이전 청크 해제

memcpy(p2 + 0x4000, elem, 16);   // 새 청크 메타데이터를 16바이트 오버플로로 손상

1025번째 항목 처리에서 새로 할당한 버퍼의 다음 청크(메타데이터)가 손상되고, 이후 반복에서도 비슷한 패턴으로 "새 할당 → 이전 해제 → 다시 오버플로"가 계속된다.
LFH의 랜덤한 재사용 때문에 언젠가 이 손상된 청크를 할당하거나 해제하는 순간 충돌이 발생하므로, 힙 상태를 먼저 "정돈"해 이 손상된 청크에 다시는 손이 가지 않게 만들어야 한다.

셰이더와 URB: 두 가지 핵심 힙 객체

게스트에서 0x4000 크기의 힙 청크를 안정적으로 만들고 제어하기 위해 두 가지 객체를 사용한다.
하나는 "많이 뿌려서 힙을 채우는 용도", 다른 하나는 "정밀하게 손상시키고 읽어내는 용도"다.

셰이더는 그래픽 가속기에서 사용하는 컴파일된 셰이더 객체로, 게스트가 거의 임의의 데이터를 포함하도록 만들 수 있다.
수백 개 이상을 손쉽게 상·하위에서 할당 및 해제할 수 있어, 특정 사이즈 클래스의 LFH 버킷을 공격자가 원하는 패턴의 데이터로 채우는 데 이상적이다.
다만, 셰이더의 내부 데이터를 게스트가 직접 다시 읽어올 수는 없으므로, "스프레이 및 패턴 채우기용"에 가깝다.

URB(USB Request Block)는 VMware의 USB 에뮬레이션에서 사용되는 전송 구조체이다.
헤더는 refcount, 데이터 길이, 실제 전송 길이(actual_len), 파이프 및 연결 리스트 포인터 등 여러 필드를 가지고 있고, 뒤쪽에는 가변 길이 사용자 데이터 버퍼가 붙는다.
URB는 게스트가 기본적으로 FIFO 큐로 관리하며, 데이터 수신 후 "reap" 같은 동작으로 내용을 읽어 오고, 데이터가 모두 소진되면 해제된다.

URB는 힙에서 크기와 구조가 잘 알려진 덩어리이고, 헤더에 포인터와 길이 정보를 담고 있기 때문에 "손상 대상으로 매우 매력적"이다.
하지만 URB는 대량 스프레이가 어렵고 생성 순서대로만 해제되므로, 힙 레이아웃을 다듬는 용도보다는 "정밀한 데이터 손상 및 정보 유출을 위한 타깃"으로 사용된다.

결국 전략은 간단하다.
셰이더로 LFH 버킷을 원하는 패턴으로 채우고 비워서 배치를 맞추고, URB는 그 사이에 끼워 넣어 손상과 유출을 담당하게 한다.

LFH 핑퐁 패턴: PING/PONG 버퍼 만들기

LFH의 랜덤성을 일부 통제하기 위해, 공격자는 먼저 해당 사이즈 클래스의 자유 청크를 모두 소진해 "기존 버킷을 꽉 채운 상태"를 만든다.
그 후 0x4000 셰이더 32개를 연속으로 할당해 버킷 두 개, B1과 B2를 가득 채운다.

B1의 셰이더 16개 중 하나만 남기고 모두 해제하면, B1에는 임의 위치의 단일 셰이더(Hole_0)만 남은 상태가 된다.
이제 15개의 URB를 할당하면, B1의 나머지 15개의 슬롯은 URB로 채워지고, Hole_0만 셰이더로 남는다.

동시에, B2에서 셰이더 하나를 해제해 B2에도 하나의 빈 슬롯을 만들고, B1의 Hole_0을 해제한다.
LFH는 "가장 최근에 해제된 청크가 속한 버킷을 우선 선택"하므로, 이후 새로 할당되는 0x4000 청크는 B1의 빈 슬롯과 B2의 빈 슬롯 사이를 번갈아 사용하게 된다.

이 두 슬롯을 PING(B1)과 PONG(B2)라고 부를 수 있고, 취약 함수의 재할당 루프는 매 반복마다 PING과 PONG 사이를 "탁구처럼 튕기며" 사용하게 된다.
그 결과, 512번째 이후 항목부터 경계 밖 쓰기가 PING과 PONG에 번갈아 적용되고, 오프셋이 16바이트씩 증가하면서 인접 청크의 메타데이터·데이터를 순차적으로 덮어 쓰게 된다.

1025번째 할당은 B2의 PONG 옆 청크 헤더를 손상시키지만, 그 청크를 다시는 해제하거나 할당하지 않도록 설계하면 LFH 체크섬 검사를 피할 수 있다.
그 다음 1026번째 할당은 B1의 PING을 사용해 바로 뒤의 URB 데이터 영역 첫 16바이트를 손상시키되, 메타데이터 영역은 건드리지 않는다.
이후 PING과 PONG 자리를 다시 셰이더로 채워 버킷을 안정된 상태로 되돌리면, "손상된 청크는 건드리지 않고, URB만 원하는 대로 여러 번 손상"할 수 있는 발판이 생긴다.

Reap Oracle: 어떤 URB가 손상됐는지 알아내는 방법

URB를 15개 할당해서 B1을 채워 놓으면, 그 중 하나의 actual_len 필드가 핑퐁 오버플로로 0이 되어 있다.
하지만 힙 주소를 모르는 상태에서는 "어느 URB가 덮어 써졌는지" 알 수 없다.

여기서 '리프(수확) 오라클' 아이디어가 등장한다.
게스트는 UHCI 컨트롤러에 대해 URB reap 호출을 반복할 수 있고, 이는 FIFO 큐의 다음 URB를 가져와 길이와 데이터를 게스트에 넘겨 준 뒤 해제한다.
이 과정을 통해 각 URB의 actual_len을 직접 확인할 수 있다.

정리하면 다음과 같다.
먼저 15개의 URB를 B1에 할당하고, 핑퐁 취약점을 한 번 실행해 인접 URB의 actual_len을 0으로 만든다.
그 뒤 URB 큐를 순서대로 reap하면서 각 URB의 길이를 확인하고, 그 자리에 새로운 셰이더를 할당한다.
actual_len이 0인 URB를 발견한 순간, 방금 그 자리에 들어간 셰이더가 "손상된 URB 바로 뒤에 위치한 슬롯"이라는 사실을 알 수 있다.

이 슬롯을 Hole_1로 이름 붙이고, 같은 패턴으로 Hole_2, Hole_3도 찾아간다.
그 결과, 같은 버킷 B1 안에 연속한 네 개의 슬롯(Hole0~Hole3)을 정확하게 특정할 수 있고, 필요할 때 이 네 슬롯을 비워서 "연속된 네 개의 0x4000 청크"를 원하는 객체로 채울 수 있는 능력을 얻게 된다.

병합(coalescing) 알고리즘을 이용한 정밀 오버플로

PVSCSI는 S/G 항목을 내부 배열에 복사한 뒤, 서로 인접한 메모리 영역을 나타내는 항목들을 하나로 합치는 병합(coalescing) 과정을 실행한다.
이 과정은 오버플로까지 포함해 복사된 "전체 S/G 배열"에 대해 수행되므로, 범위를 벗어난 항목들도 병합의 대상이 된다.

병합의 핵심 규칙은 단순하다.
현재 항목 A의 addr + size가 다음 항목 B의 addr과 같으면 "연속된 메모리"로 간주하고 둘을 하나로 합친다.
병합이 일어나면 뒤쪽 항목들이 앞으로 당겨지면서 배열이 압축된다.

또한, 게스트는 32비트 length를 제공하지만, 병합에서 사용하는 entry_size는 64비트로 확장되어 사용된다.
최대 크기(0xFFFFFFFF) 항목들을 많이 더하면 64비트 합의 상위 비트를 조작할 수 있어, 일부 바이트(예를 들면 13번째 바이트의 최하위 비트)를 제어할 수 있게 된다.

공격자는 이 병합 메커니즘을 이용해 두 가지를 달성한다.
첫째, 범위 밖에 흩어져 쓰인 가짜 S/G 항목들을 병합·압축 과정에서 "위쪽으로 끌어올려" 특정 URB 구조체를 완전히 덮어쓴다.
둘째, 길이가 0인 항목과, 같은 addr을 가진 길이가 실제 값인 항목을 짝지어, 병합 후 "주소와 길이 모두 완전히 임의로 제어된 항목"을 얻는다.

예를 들어 URB1에 {0x41414141..., 0x42424242...}를 쓰고 싶다면, URB1 영역에 들어갈 S/G 항목을 다음처럼 준비한다.

entry[i]   = {addr = 0x4141..., size = 0}
entry[i+1] = {addr = 0x4141..., size = 0x4242...}

병합 후 entry[i]는 {addr = 0x4141..., size = 0x4242...}가 되고, 이것이 병합·압축 과정에서 URB1 메모리 영역으로 복사되면서 원하는 값이 정확히 써진다.
이렇게 하면, "마지막 4바이트가 항상 0이 된다"는 원래 오버플로 제약을 우회하고도 64비트 필드를 완전히 임의로 덮어쓸 수 있게 된다.

이 기법을 기반으로 공격자는 URB 구조체 전체를 원하는 값으로 재구성할 수 있는 강력한 원시(primitive)를 얻는다.
다만 이 상태에서 포인터를 엉뚱한 곳으로 향하게 하면 곧바로 크래시가 나므로, 먼저 안전한 정보 유출이 필요하다.

URB 누출: 병합으로 만든 프랑켄슈타인 URB

URB 정보 유출의 목표는 URB 헤더에 담긴 포인터(예: USB 파이프 구조체 포인터, 연결 리스트 포인터)를 빼내 힙 ASLR을 깨는 것이다.
직접 actual_len을 크게 만들어 OOB read를 만들 수 있다면 쉽지만, 오버플로 제약상 actual_len은 0으로만 만들 수 있다.

이를 우회하기 위해, 공격자는 병합 과정을 활용해 "두 개의 URB를 섞은 하이브리드 URB"를 만드는 전략을 사용한다.
힙 레이아웃은 연속된 네 슬롯을 다음과 같이 배치하는 것으로 시작한다.

  • Hole0: 이후 오버플로를 시작할 PING 버퍼

  • URB1: 손상 대상 URB

  • URB2: 헤더를 가져다 쓸 정상 URB

  • URB3: 최종적으로 내용을 유출하고 싶은 URB

오버플로를 두 번(홀수/짝수 인덱스) 실행해 URB1과 URB2 영역을 가짜 S/G 항목으로 채운다.
이때 URB1 영역의 가짜 항목들은 주소가 연속적이고 크기가 모두 0xFFFFFFFF인 "긴 연속 구간"처럼 보이도록 만든다.

병합이 시작되면, PVSCSI는 URB1 영역 내의 S/G 항목이 모두 연속된 것으로 판단해 하나의 큰 항목으로 합친다.
이때 길이 합산은 0xFFFFFFFF * n과 같이 매우 커지는데, 이 64비트 결과의 상위 32비트가 URB1 헤더 안의 actual_len 위치에 정확히 들어가도록 설계해 두면, 결과적으로 actual_len이 0x400 같은 유효한 값으로 세팅된다.

병합 이후 "데이터 압축" 단계에서, URB1 뒤에 있던 데이터(URB2의 일부 헤더)를 URB1 영역 안으로 끌어올리면서, URB1의 헤더는 "URB2 헤더의 복사본 + 새 actual_len"이 된다.
URB1의 data_ptr은 URB2의 원래 데이터 버퍼를 가리키게 되는데, 이 버퍼는 우연히도 URB3 바로 앞에 있다.

이제 게스트가 URB1을 reap하면, VMware는 data_ptr에서 actual_len(0x400) 바이트를 게스트로 복사한다.
이 과정에서 URB2 데이터의 끝을 지나 URB3의 헤더와 내용까지 함께 넘어오게 되므로, 사실상 URB3에 대한 OOB read가 구현된다.

이렇게 얻은 URB3 헤더에는 USB 파이프 구조체 포인터, 자기참조 포인터 등 힙 내부 주소 정보가 들어 있어, 이를 이용해 LFH 버킷 내의 정확한 주소(Hole0~Hole3 위치 등)를 계산할 수 있다.
즉, 이 단계에서 힙 ASLR을 사실상 무력화하게 된다.

임의 읽기·쓰기·호출로 이어지는 마지막 단계

URB 헤더 유출로 힙 레이아웃의 실제 주소를 알게 되면, 이후 단계는 상대적으로 단순하다.
핵심은 "URB1을 완전히 가짜 구조체로 덮어쓰되, VMware가 보기엔 여전히 정상적으로 동작하는 URB로 보이게" 만드는 것이다.

우선, 이전에 URB3가 있던 자리에 Shader3를 다시 할당해 이 청크를 데이터 소스로 사용한다.
Shader3 안에 "조작된 URB 구조체"를 넣어 두고, 앞서 사용한 병합·압축 기법을 이용해 Shader3 내용을 URB1 메모리 영역으로 복사한다.
이렇게 하면 URB1은 공격자가 원하는 값으로 채워진 가짜 URB가 된다.

다음으로, 이 가짜 URB가 힙에서 사라지지 않도록 영구적인 형태로 만들어야 한다.
URB1의 refcount를 올려 해제되지 않게 만들고, URB1.next 포인터를 Hole0 위치를 가리키도록 조정한다.
그 후 VMware가 URB1을 한 번 reap하면, URB 큐의 헤드가 Hole0에 위치한 가짜 URB로 바뀌고, 이후에는 게스트가 Hole0을 새 셰이더로 덮어쓰는 것만으로 큐 맨 앞의 URB를 원하는 구조로 재정의할 수 있다.

이제 임의 읽기·쓰기는 다음과 같이 구현된다.

  • 임의 읽기: Hole0 셰이더에 data_ptr = 읽고 싶은 주소, actual_len = 읽고 싶은 길이를 갖는 가짜 URB를 써 넣고, 해당 URB를 reap해 반환된 데이터를 게스트에서 확인한다.

  • 임의 쓰기: URB의 pipe 포인터가 가리키는 구조체와 UHCI의 TDBuffer 쓰기 메커니즘을 이용해, 원하는 주소에 원하는 32비트 값을 쓸 수 있도록 pipe와 관련 필드를 조작한다.

마지막으로 임의 호출은 USB 파이프 객체의 콜백 함수 포인터를 변조하는 방식으로 구현된다.
URB가 처리될 때 해당 콜백이 항상 호출되므로, 콜백 포인터를 ROP 가젯이나 WinExec를 호출하는 래퍼(화이트리스트에 등록된 CFG 통과 가젯)로 바꾸면, URB 처리 과정에서 임의의 함수 호출이 가능해진다.

Windows 버전마다 vmware-vmx의 주소와 오프셋이 다를 수 있으므로, 하드코딩 대신 임의 읽기 기능을 이용해 프로세스 메모리에서 Kernel32를 찾고, 내장된 PE 구조를 파싱해 WinExec 주소를 동적으로 계산한다.
CFG 우회를 위해서는 vmware-vmx 내부의 유효한 간접 호출 가젯(화이트리스트에 등록된 대상)을 찾아, 그 가젯이 RCX에 실린 문자열 인자를 그대로 사용해 WinExec("calc.exe")를 부르는 흐름을 구성한다.

이렇게 하면, LFH의 초기 상태만 정확히 알 수 있다면 매우 안정적인 VM 탈출 익스플로잇이 완성된다.

타이밍 사이드 채널로 LFH 무작위화 깨기

실제 대회 환경에서는 가장 큰 문제가 "LFH가 처음에 얼마나 채워져 있는지 모른다"는 점이었다.
게스트 OS가 부팅되고 GUI 세션이 시작되면 다양한 0x4000 할당이 발생해, 버킷 안에 이미 여러 청크가 사용 중인 상태가 된다.
테스트 환경마다 이 초기 상태가 조금씩 달라서, "16개 후보 중 하나를 찍는 정도"의 정보만 가진 채 시작하는 셈이었다.

여기서 아이디어는 "새 버킷이 만들어지는 순간은 기존 버킷에서 그냥 할당할 때보다 시간이 더 걸릴 것"이라는 가설이었다.
0x4000 할당을 여러 번 해가며 각 할당 시간을 정밀하게 측정하면, 어느 시점에서 버킷 생성이 일어났는지 감지할 수 있고, 이는 곧 현 시점에서 버킷에 몇 개의 청크가 사용 중인지(=오프셋)를 알려준다.

문제는 VMware 내부의 일반적인 인터페이스들은 대부분 비동기라는 것이다.
그래픽 명령처럼 FIFO에 넣는 방식은 실제 호스트 할당 시점과 게스트에서 명령을 보낸 시점이 분리되므로, 정확한 타이밍 측정이 불가능하다.

이를 해결하기 위해 사용된 것이 VMware 백도어 채널이다.
이는 특수한 IN 명령을 통해 VMware Tools 기능(클립보드, RPC 등)을 동기적으로 호출하는 인터페이스로, 명령 처리가 끝난 뒤에야 제어가 게스트로 돌아온다.

예시는 다음과 같다.

#define VMW_BACKDOOR "inl %%dx, %%eax"

static inline uint32_t vmware_cmd_guestrpc(int channel,
                                           uint16_t subcommand,
                                           uint32_t parameter,
                                           uint16_t *edxhi,
                                           uint32_t *ebx) {
    uint32_t discard_a, status, edx;
    __asm__ __volatile__(VMW_BACKDOOR
        : "=a"(discard_a),"=b"(*ebx),"=c"(status),"=d"(edx)
        : "0"(VMW_MAGIC),"1"(parameter),
          "2"(VMW_CMD_GUESTRPC | (subcommand << 16)),
          "3"(VMW_PORT | (channel << 16)));
    *edxhi = (edx >> 16);
    return status;
}

연구팀은 vmx.capability.unified_loop라는 명령에 0x4000 크기 문자열을 인자로 넘겨, 호출할 때마다 호스트가 0x4000짜리 버퍼 두 개를 할당하도록 만들었다.
버킷 하나가 16청크이므로, 이 명령을 8번 호출하면 정확히 16개의 0x4000 할당이 일어나고, 그 중 어느 호출에서 새 버킷이 만들어졌는지 타이밍을 통해 탐지할 수 있다.

각 호출 전후로 gettimeofday를 통해 시간을 재고, 명령 8개에 대한 시간을 한 배치로 묶는다.
호스트 컨텍스트 스위칭 등으로 인해 특정 측정값이 지나치게 커진 배치는 버리고, 여러 배치의 데이터를 합산해 평균적인 패턴을 만든다.
그 결과, 8개 값 중 하나가 일관되게 다른 것보다 길게 나오는 인덱스를 찾을 수 있고, 이 인덱스가 바로 "버킷 생성이 일어난 자리"가 된다.

이어 0x4000 버퍼 하나를 추가로 할당한 뒤 같은 과정을 반복해, "버킷 생성 위치가 그대로인지, 다음 인덱스로 밀렸는지"를 확인하면, 현재 오프셋이 홀수인지 짝수인지까지 구분할 수 있다.
이 정보를 바탕으로 LFH 버킷 안에서 정확히 몇 번째 청크부터 스프레이를 시작해야 하는지 역산할 수 있고, 이는 전체 익스플로잇 체인이 요구하는 "LFH 초기 상태를 안다"는 가정을 실제로 만족시켜 준다.

다만 vmx.capability.unified_loop는 부작용이 있다.
이 명령으로 만든 문자열은 글로벌 리스트에 쌓이면서 해제할 수 없고, 새 문자열이 추가될 때마다 기존 리스트와의 중복 여부를 O(n)에 가깝게 비교한다.
따라서 측정 배치가 많아질수록 리스트 길이가 증가해, 명령 자체의 기본 지연이 커지고 노이즈도 증가하는 역설이 발생한다.

결국 연구팀은 "너무 많은 배치로 SNR을 올리려다 오히려 측정 환경을 오염시키지 않도록" 배치 수와 필터링 기준을 조절하는 실험을 반복했다.
이 조정 끝에, 제한된 횟수의 측정만으로도 대부분의 경우 안정적으로 LFH 상태를 알아낼 수 있었고, 실제 대회에서도 한 번에 성공했다.

인사이트

이 사례의 핵심은 "강한 방어가 있다고 해서 취약점이 약해지는 것은 아니다"라는 점이다.
LFH의 랜덤 할당, 체크섬 메타데이터, CFG와 같은 방어기법도, 그 동작을 충분히 이해하고 나면 오히려 공격에 필요한 구조적인 정보를 제공하는 단서가 될 수 있다.

실무 관점에서 얻을 수 있는 교훈은 몇 가지다.
첫째, 크기 고정 재할당 버그처럼 "단순해 보이는 메모리 취약점"도, 할당자와 상호작용하는 방식에 따라 매우 강력한 공격 원시로 발전할 수 있다.
둘째, 기능성 최적화를 위해 추가한 로직(예: 병합 알고리즘이나 URB 길이 계산)이 공격자가 제약을 우회하는 통로가 될 수 있으므로, 설계 단계부터 보안 관점에서 검토해야 한다.
셋째, 타이밍 같은 사이드 채널은 단지 이론적 위험이 아니라, 실제로 ASLR·무작위화 우회를 위한 실용적인 도구로 사용될 수 있다는 점을 염두에 두어야 한다.

연구나 CTF, 실무 취약점 분석에서 비슷한 문제를 마주했다면, 단일 버그만 바라보지 말고 "할당자·프로토콜·병합·큐 잔여 상태·타이밍" 등 시스템 전체 흐름을 하나의 퍼즐로 보고, 조합 가능한 조각들을 찾는 연습을 해보면 좋다.
이 과정 자체가 고급 익스플로잇 기술을 익히는 가장 효과적인 훈련이 된다.

출처 및 참고 : 시간 제한: Pwn2Own 베를린 2025에서 VMware Workstation 탈출하기

#VMware#힙 오버플로#LFH#익스플로잇#사이드 채널

이 노트는 요약·비평·학습 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.

Tilnote 를 사용해 보세요.

키워드만 입력하면 나만의 학습 노트가 완성돼요.

책이나 강의 없이, AI로 위키 노트를 바로 만들어서 읽으세요.

콘텐츠를 만들 때도 사용해 보세요. AI가 리서치, 정리, 이미지까지 초안을 바로 만들어 드려요.