Firecracker microVM 탈출: PwnEscape 2부, 게스트에서 호스트 root 코드 실행

Nova 마이크로하이퍼바이저 방식이 맞다고 요즘 더 확신함. 검증된 작은 마이크로커널로 가상화하고 리눅스 같은 복잡한 커널은 그 밑에서 돌리는 게 낫지. hypervisor.org

그 Nova 코드에 실험적이고 기능도 완성 안 됐다고 적혀 있던데. 깨지면 조각이나 챙기라는 식임.

Xen이나 Hyper-V랑 뭐가 다름? 하이퍼바이저를 별도 컴포넌트로 두고 Dom0에서 관리하는 구조는 같은데. KVM은 하이퍼바이저가 Dom0 안에서 도는 거고.

1990년대 후반부터 L4도 같은 얘기 했음. 성숙한 L4 구현이 여러 개 있음.

Firecracker는 AWS에서 돌아가는데 기사에 그 얘기가 하나도 없네.

Firecracker는 오픈소스라 다른 데서도 쓰고, AWS는 그걸로 서비스 팔 뿐임.

기사 디테일이 너무 부실함. LLM 슬롭임.

AWS 보안 공지 보면 이 이슈로 영향 없음이라고 나옴.

LLM 슬롭이라고 하기엔 이건 취약점 발견자들이 직접 쓴 글이고, 최근 기억으로 nested virtualization 없이 되는 첫 범용 Firecracker 탈출임. 대체 소스도 없음.

새로운 취약점 아님. 몇 주 전 공개된 PwnEscape를 Firecracker에서 실제로 익스플로잇하는 방법 설명임.

HN에서 이미 길게 논의됐다는 건데 못 찾겠음. 링크 좀.

ClickBench playground(https://benchmark.clickhouse.com/playground/)는 Firecracker VM으로 110개 넘는 DB 엔진을 돌림. Pandas 같은 건 사실상 열린 RCE라서 여기서 PoC 해볼 수 있음.

그거 익스플로잇 실제로 돌려보고 확인한 거임? 그럼 왜 광고함? 이미 패치했나.

gVisor도 내부적으로 KVM 씀. microVM이랑 완전히 별개가 아님.

gVisor가 공정한 비교에서 더 강할 거란 생각은 안 듦. 취약점은 거의 다 I/O 코드에 있고 컨테이너든 VM이든 샌드박스든 I/O는 다 있음.

jailing 부분을 더 설명해줬으면 함. jailer로 권한 강등하고 namespace, seccomp 걸면 피해 범위가 확 줄어들 텐데. 프로덕션은 이미 그렇게 하고 있을 거고, 근본 원인은 커널 네트워크 코드 문제임.

jailer 경계까지만 증명한 거면 실제 호스트 장악에는 별개의 LPE가 하나 더 필요함.

아님. 익스플로잇은 호스트 커널을 침해함. 거기서 Firecracker 사용자 공간을 노린 것뿐이고 다른 대상도 가능했을 거임.

최근 다른 Firecracker 탈출(coinspect 블로그)은 io_uring으로 jailer를 뚫었음. seccomp로 걸러도 자기가 만든 uring은 필터가 안 걸려서 새 uring을 열게 만드는 방식임.

jailer 없이 Firecracker 쓰는 건 비밀번호를 password로 설정하는 거랑 같음. 이건 Firecracker 문제가 아니라 커널 네트워킹 문제임.

illumos랑 FreeBSD용 microVM 솔루션 Firehyve 만드는 중임. jailed zone 안에서 돌리면 마음이 좀 놓임. 완벽하진 않지만 방어 계층이 하나 생기니까.

게스트가 호스트 Firecracker 사용자 공간에 어떻게 쓰는지 설명이 없음. 디버거 붙여서 프로세스 멈추고 포인터 바꾸는 건 2-3분이면 됨.