글에서 jailer를 사용하지 않은 구성이라는 대목을 더 자세히 다뤘으면 좋겠음. 운영 환경의 Firecracker는 권한을 낮추고 네임스페이스와 seccomp로 프로세스를 제한하며, 이런 환경에서는 VMM을 장악한 뒤 이용할 수 있는 권한과 자원을 별도로 평가해야 한다고 적혀 있음.
내가 제대로 이해했다면, 올바르게 격리하고 설정한 Firecracker는 이번 탈출의 피해 범위를 크게 줄일 수 있음. 격리와 권한 축소가 어떻게 도움이 되는지 설명했어야 하며, 대부분의 운영 환경에서는 이미 적용하고 있기를 바람.
심각성을 낮게 보려는 건 아니지만, 근본 원인은 Firecracker 자체가 아니라 커널 네트워크 코드의 결함임. 안전하지 않은 Firecracker 구성으로 시연했을 뿐인데, 이를 Firecracker의 결함으로 받아들이는 듯해 아쉬움.
입증된 공격 범위가 jailer 경계까지라면, 실제 호스트 제어권을 얻으려면 별도의 상당히 강력한 로컬 권한 상승(LPE) 취약점이 필요함.
Firecracker가 아니라 커널 네트워크 스택의 결함임. jailer 없이 Firecracker를 쓰는 건 비밀번호를 password로 설정하는 것과 같음.
최근의 다른 Firecracker 탈출은 io_uring으로 jailer를 뚫었음. Firecracker는 seccomp로 시스템 호출을 적절히 필터링했고 자신이 생성한 io_uring도 필터링했지만, 공격자는 새로 필터링되지 않은 io_uring을 생성하게 만들었음.
그렇지 않음. 이 공격은 호스트 커널을 장악함. 연구진은 호스트 커널 장악을 이용해 호스트의 Firecracker 사용자 공간 코드를 장악하는 특이한 공격 체인을 구성했지만, 호스트 커널의 다른 대상을 장악하지 못할 근본적인 이유는 없어 보임.
갈수록 Nova Microhypervisor의 접근법이 옳다는 확신이 커짐. 거대하고 복잡하며 취약한 Linux 커널과 VM 생태계에 하이퍼바이저 계층을 맡기기보다, 형식 검증된 작은 마이크로커널로 가상화를 수행하고 Linux 같은 복잡한 커널은 그 아래에서 실행해야 함. https://hypervisor.org/
Xen이나 Hyper-V와 어떻게 다른가? 하이퍼바이저를 독립 구성 요소로 두고, 그 위에서 하이퍼바이저를 관리하는 가상화된 Dom0 또는 Root Partition을 부팅하는 동일한 접근법으로 보임.
하이퍼바이저가 Dom0/Root Partition 안에서 실행되는 KVM과는 다름.
Nova는 잘 모르지만, L4도 1990년대 후반부터 같은 방향을 내세웠고 성숙한 구현체가 여럿 있음.
시간을 아끼도록 프로젝트의 안내를 가져옴. “이 코드는 실험적이며 기능이 완성되지 않았음. 망가지면 그 결과는 직접 감당해야 함.”
Firecracker VM에 전적으로 의존하는 데모 서비스인 ClickBench playground를 운영 중임. https://benchmark.clickhouse.com/playground/.
수백 개의 데이터베이스 엔진을 호스팅하며, 상당수에 취약점이 있고 Pandas 같은 일부는 사실상 원격 코드 실행이 열려 있는 것이나 마찬가지임. 이 서비스에서 Firecracker VM 탈출 개념 증명(PoC) 을 시도해 볼 수 있음.
110개 이상의 데이터베이스에 SQL을 실행할 수 있다니, 지금껏 본 웹 도구 중 손꼽히게 유용함. 주로 데이터베이스용 데이터 소스 커넥터를 개발하는데, 정렬 동작이나 같은 함수를 여러 DB에서 흉내 내는 방법을 빠르게 시험할 수 있었다면 일이 훨씬 쉬웠을 것 같음.
새로운 취약점이 아니라, 몇 주 전 공개된 PwnEscape를 Firecracker VM에서 실제로 악용하는 방법을 설명한 글임. HN에서도 추천 수가 적었던 다른 게시물들에서 다뤘음.
illumos와 FreeBSD용으로 Firecracker와 비슷한 microVM 솔루션인 Firehyve를 개발 중임. https://github.com/TritonDataCenter/rshyve.
microVM을 격리된 zone 안에서 실행하니 조금은 안심됨. zone 탈출 취약점이 숨어 있을 수 있어 완벽하지는 않지만, 적어도 방어 계층 하나는 추가됨.
이 글의 PoC는 zone과 본질적으로 비슷한 역할을 하는 Firecracker jailer를 뚫지는 못함. 그래도 양쪽 모두 큰 위안은 되지 못함. 권한 없는 샌드박스 안에서도 로컬 권한 상승에 악용될 수 있는 거대한 커널 공격 표면이 남기 때문임.
Replit 샌드박스 엔진 글에도 비슷한 질문을 남겼는데, microVM의 하드웨어 격리와 gVisor 같은 강력한 소프트웨어 격리를 어떻게 비교하는가?
지금은 하드웨어 격리를 매우 신뢰하지만, 에이전트가 이를 상당한 수준으로 뚫기 시작하면 패치 가능한 소프트웨어 격리에 더 의존하게 될지 궁금함. 소프트웨어 RAID가 부상했던 것과 비슷하되, 이번에는 사용자 공간에서 일어날 수도 있음.