Firecracker VM 탈출: PwnEscape 2부 분석

Firecracker 탈출 개요

이 익스플로잇은 Firecracker microVM 내부에서 호스트 머신의 루트 수준 코드 실행을 달성하는 방법을 보여줍니다. 호스트 메모리 프리미티브를 활용하여 공격자는 Firecracker 프로세스를 찾고, 활성 vCPU 스레드를 식별하며, KVM_RUN 시스템 호출에서 반환될 때 실행을 리디렉션하도록 저장된 레지스터 상태를 수정할 수 있습니다.

호스트 프로세스 및 vCPU 스레드 찾기

익스플로잇 체인은 게스트와 관련된 호스트 측 리소스를 식별하는 데 의존합니다. 먼저 게스트는 메모리 페이지에 고유한 nonce를 배치하고, 이는 EPT(Extended Page Table) 워킹을 사용하여 호스트 물리 메모리에서 위치가 파악됩니다. 이 페이지의 HPA(Host Physical Address)가 식별되면, 공격자는 호스트의 페이지 테이블을 사용하여 역매핑을 수행함으로써 Firecracker 프로세스와 해당 PGD(Page Global Directory)를 식별합니다.

호스트 PGD와 Firecracker 바이너리의 로드 바이어스(ASLR에 탄력적인 매핑을 통해 ELF 이미지를 식별하여 결정됨)를 확보하면, 공격자는 프로세스의 메모리를 검사할 수 있습니다. 이 단계의 마지막은 활성 vCPU 스레드에 대한 pt_regs 구조를 찾는 것입니다. 공격자는 실행 중인 microVM과 관련된 특정 명령어 포인터, 스택 포인터 및 파일 디스크립터를 포함하여 예상되는 KVM_RUN ioctl 상태와 일치하는 프레임을 검색합니다.

실행 리디렉션 및 페이로드 전달

저장된 레지스터 프레임이 위치하면, 공격자는 스레드의 실행 컨텍스트를 수정하여 악성 페이로드를 주입합니다. 저장된 명령어 포인터와 스택 데이터를 덮어씀으로써, 공격자는 Firecracker 프로세스가 자체 stderr에 write(2) 호출을 실행하도록 강제하여 제어권을 증명합니다.

안정성을 보장하기 위해 익스플로잇은 ROP(Return-Oriented Programming) 방식을 사용합니다:

1. 스레드는 선택한 작업을 실행하기 위해 write 래퍼로 리디렉션됩니다.
2. 예상치 못한 반환 값으로 인해 원래의 KVM_RUN 로직이 실패하는 것을 방지하기 위해 xor eax, eax; ret 시퀀스를 사용하여 반환 값을 지웁니다.
3. 스레드는 원래의 실행 경로로 돌아가고, VMM이 충돌하는 것을 방지하기 위해 임시 스택 수정 사항이 복원됩니다.

보안 컨텍스트 및 완화 조치

이 시연은 jailer를 사용하지 않은 Firecracker v1.16.1에서 수행되었습니다. jailer 유틸리티, seccomp 필터 및 네임스페이스 격리를 포함하는 Firecracker의 프로덕션급 격리 기능은 이러한 탈출의 영향을 크게 줄이도록 설계되었다는 점을 유의해야 합니다.

"적절하게 jailer가 적용되고 구성된 firecracker 인스턴스는 이 탈출의 피해 범위를 크게 줄일 것입니다... 대부분의 프로덕션 firecracker 배포 환경에서는 이미 이렇게 하고 있기를 바랍니다. 이것이 덜 심각하다거나 근본적인 문제가 Firecracker에만 국한된 것이라고 말하는 것은 아니며, 커널 네트워크 코드의 결함에 기인한 것입니다. 그들은 단지 이를 시연하기 위해 안전하지 않은 firecracker 구성을 사용했을 뿐입니다." — Commenter @scoodah

이 익스플로잇은 강력한 프리미티브를 보여주지만, 프로덕션 환경에서의 성공 여부는 호스트의 샌드박스 구성 효율성에 달려 있습니다. 근본적인 취약점은 게스트가 호스트 측 프로세스 메모리와 상호 작용할 수 있게 하는 메모리 액세스 프리미티브와 관련된 위험을 강조합니다.