요약
Firecracker 마이크로VM 안의 게스트가 호스트에서 루트로 도는 VMM 프로세스를 장악했습니다.
보안 연구 조직 PWN Research의 파울로스 이벨로가 쓴 PwnEscape 연재의 2부입니다. 1부에서 리눅스 네트워킹 결함으로 얻은 호스트 메모리 접근 능력을, VMM(게스트를 띄우고 관리하는 호스트 쪽 프로그램)에서 코드를 실행하는 데까지 이어 갔습니다.
왜 중요한가
- 신뢰할 수 없는 코드를 가두려고 쓰는 마이크로VM 경계를 게스트 쪽에서 넘을 수 있음을 보였습니다.
- 시연은 jailer(권한을 낮추고 프로세스를 격리하는 보조 도구) 없이 루트로 띄운 설정이었습니다.
- 그래서 jailer를 쓰는 운영 환경의 피해 범위는 따로 따져 봐야 한다고 글이 밝혔습니다.
핵심 내용
- vCPU 스레드가 KVM_RUN 호출 중 커널에 저장해 둔 레지스터 값(pt_regs)을 고쳐 돌아갈 위치를 바꿨습니다.
- 그 결과 Firecracker가 루트 권한으로 write 함수를 불러 stderr에 8바이트 표식을 찍었습니다.
- 대상을 찾으려고 게스트 페이지에 표식 값을 쓰고 EPT(게스트 주소를 호스트 주소로 옮기는 표)를 뒤졌습니다.
- 이어 호스트 페이지 테이블을 거슬러 Firecracker 프로세스와 실행 파일의 주소 배치를 알아냈습니다.
- 게스트가 직렬 포트에 1바이트를 쓰자 실행이 일어났고, 이후에도 Firecracker와 게스트 SSH는 멀쩡했습니다.
HN 반응
- jailer 없는 시연이라 피해가 제한적이라는 의견에, 호스트 커널을 뚫었으니 jailer 밖의 프로세스를 노리면 된다는 반론이 나왔습니다.
- 개념 증명 코드가 /dev/mem으로 메모리를 직접 고쳐 핵심 단계를 감췄다는 비판과, 클라우드 업체들이 급히 재부팅할 만큼 심각하다는 평가가 엇갈렸습니다.
이 문단을 글에서 좀 더 자세히 다뤄 줬으면 정말 좋았을 텐데요.
제가 이해한 게 맞다면, jailer와 설정이 제대로 갖춰진 firecracker 인스턴스에서는 이 탈출의 피해 범위가 크게 줄어들 겁니다. 그러니 jailing과 권한 낮추기가 구체적으로 어떻게 도움이 되는지 설명해 줬으면 좋았겠다는 생각이 듭니다. 실제 운영 환경의 firecracker 배포라면 대부분 이미 그렇게 하고 있을 거라고 믿고 싶고요.
그렇다고 이 문제가 덜 심각하다는 말은 아닙니다. 근본 원인도 Firecracker가 아니라 커널 네트워크 코드의 결함에 있고, 이들은 시연을 위해 안전하지 않은 firecracker 구성을 썼을 뿐입니다. 그런데도 Firecracker의 결함으로 받아들이는 사람들이 있는 것 같습니다. 그렇지 않습니다. 이건 커널 네트워킹 스택의 문제입니다.
좋은 지적입니다. 맞아요, 이들이 증명한 건 jailer 경계까지뿐이라서, 이걸로 호스트를 실제로 장악하려면 상당히 강력한 로컬 권한 상승(LPE) 취약점이 하나 더 필요합니다.
최첨단 추론 에이전트 덕분에 리눅스에서 LPE 취약점 900개 이상을 찾아낼 수 있을 만큼 구멍투성이라는 게 드러났습니다. [0]
이런 취약점은 앞으로도 한 차례 더 쏟아져 나올 겁니다. C와 C++로 만든 OS와 커널이 수백 개의 AI 에이전트 앞에서 얼마나 허약한지 이제 막 보이기 시작한 거예요.
[0] https://openai.com/index/a-thousand-fewer-paths-to-root/
AI가 찾아낸 첫 번째 이슈들에 대한 Hartman의 반응을 한번 보세요. 지독하게 무시하고 무지한 태도였습니다.
이 사태를 만든 사람들이 직접 고치게 될지는 잘 모르겠습니다.
이 사태를 만든 사람들(리눅스를 단단하게 만드는 대신 주로 광고를 더 빨리 서빙하게 만든 쪽?)이 지금 해독제를 밀고 있는 사람들과 똑같은 사람들이 아니라고 확신하세요?
그 취약점 중에 레거시 하드웨어나 파일시스템 지원 코드에 있는 건 얼마나 되죠? 최신 리눅스 설치본에 대한 위협과는 전혀 상관없는 것들 말이에요. 압도적 다수가 그럴 거라고 봅니다.
위에 링크된 OpenAI의 최근 발표는 전체 약 4,000만 SLoC 중 약 300만 SLoC만 대상으로 했습니다. 단순한 VM 게스트 안에서 닿을 수 있는 핵심 시스템 코드입니다.
이건 우리가 늘 알고 있던 얘기입니다. 모놀리식 커널 OS가 등장한 초창기부터 어딘가에는 항상 권한 상승 경로가 있다는 건 이해되어 온 사실이에요. 셸이 더 나은 선택일 웹 애플리케이션에서조차 사람들이 CGI 방식 인터페이스를 고르는 이유가 이겁니다.
그동안 문제로 여겨지지 않았던 유일한 이유는, 그런 취약점을 찾아서 공략하는 데 들어가는 노력과 시간 때문이었습니다.
아닙니다. 이 익스플로잇은 호스트 커널을 장악합니다. 연구자들은 호스트 커널 장악을 이용해 호스트의 firecracker 유저스페이스 코드를 장악하는 비전형적인 익스플로잇 체인을 만들었지만, 호스트 커널의 다른 무언가를 장악하지 못할 근본적인 이유는 제가 보기엔 없습니다.
잠깐, 생각해 보니 이 말도 맞는 것 같네요. 메모리 공개 프리미티브는 꼼꼼하게 문서화했는데 거기서 같이 얻은 메모리 쓰기는 문서화하지 않아서 좀 헷갈립니다. 그게 뭐든 커널 메모리를 때리고 있는 거겠죠? 그런데 여기서 설명하는 익스플로잇은 커널이 아니라 Firecracker 자체에서 코드 실행을 얻는 겁니다.
제가 이해하기로는 이들이 목표로 삼은 건 호스트 유저스페이스의 pt_regs, 즉 Firecracker의 레지스터 상태를 저장하는 커널 구조체입니다. 그걸 찾아서 쓸 수만 있다면 Firecracker의 레지스터 상태 전체를 제어할 수 있어요.
대부분의 리눅스 KVM 유저스페이스가 그렇듯 [0] Firecracker도 게스트 메모리를 자기 주소 공간에 매핑하니까, 가젯을 쓰기 쉬운 자리가 생깁니다. 그래서 이걸 목표로 삼았을 거라고 짐작합니다.
제가 개인적으로 pt_regs에 가장 즐겨 넣어 보는 건 실제 특권(CPL0) 컨텍스트입니다. [1] 커널에서 복귀하면서 곧바로 제어 가능한 커널 컨텍스트로 돌아가는 건 CPU가 허용하거든요 :)
[0] 얼마 전까지는 이게 필수였습니다. 요즘은 호스트 유저스페이스 메모리에 두지 않고도 KVM에 무언가를 게스트로 매핑하라고 요청할 수 있어요.
[1] pt_regs를 망가뜨려서 유저 메모리를 커널 모드로 실행하게 만드는 방법입니다.
https://seclists.org/oss-sec/2015/q3/291
제가 지금까지 쓴 익스플로잇 중에서 가장 마음에 드는 것 같습니다. 사실 저는 제가 찾은 메모리 손상 버그에 대해서는 일부러 흥미로운 익스플로잇을 쓰지 않는 경우가 많았는데, 이건 너무 재미있어서 그냥 넘길 수가 없었어요.
고맙습니다! 이제 이해가 되네요. 그렇다면 당연히 jailer도 무의미해집니다. jailer로 격리되지 않은 프로세스를 찾아서 거기에 주입하면 되니까요.
네, 거기서 말을 많이 아낍니다. 게다가 개념 증명 코드라는 건 설명에 나온 페이지들의 물리 주소를 명령줄 인자로 그냥 넘겨받아서 /dev/mem을 열고 그 페이지들을 직접 수술하는 게 전부예요.
그러니까, 설명하는 내용의 개념 증명이라고 할 만한 게 전혀 아니라는 거죠.
"그건 원래부터 허용되던 일이다."
정말 좋은 버그예요! 다만 익스플로잇 세부 내용을 끝까지는 따라가지 못했을 뿐입니다. 이 버그 때문에 클라우드 제공업체 한 곳 이상이 전체 서버 플릿을 허겁지겁 재시작했다고 알고 있고, 저는 그게 옳은 판단이었다고 봅니다.
진짜 버그가 있는 건 분명합니다.
다만 개념 증명이 호스트 물리 메모리가 게스트 물리 메모리의 2^39 지점에 매핑되어 있다는 가정에서 출발한다는 점이 거슬려요. 실제 익스플로잇을 아직 공개할 수 없는 사정은 이해합니다. 하지만 코드에 익스플로잇이 전혀 없는데 그런 걸 "개념 증명"이라고 부르며 블로그 글을 써서는 안 되죠. 체인에서 정말 새로운 익스플로잇 부분을 빙빙 돌려 피하고 있는 게 뻔히 보이거든요. 공개 유예 기간이 끝날 때까지는 그냥 가만히 계세요.
읽으면서 "내가 중간 단계를 놓쳤나 보다" 싶은 곳이 한두 군데가 아니었어요.
1편에서 64바이트 영역을 때릴 수 있는 쓰기 프리미티브가 있다고 했는데, 그게 어떻게 동작하는지는 끝내 설명하지 않았습니다. 체크섬 오프로드가 유효한 데이터 뒤쪽 넘치는 영역에 TCP/UDP 체크섬 값을 쓰게 한 것 같아요. 메모리 맵이 그렇게 구성돼 있었을 수도 있지만, 패킷 바로 다음 페이지에 자기 페이지 테이블이 오는 엄청난 행운이 필요한 방식인 건 분명합니다.
그리고 어디에도 언급이 없지만, 제가 보기엔 이 익스플로잇은 페이지의 시작 부분만 읽고 쓸 수 있습니다. IP IHL 필드를 읽는 소켓 로직의 허를 찌르려면 IP 헤더 내용이 게스트에 매핑된 페이지에 있어야 해요. 이 공격을 쓸 수 있는 유일한 방법은 그 영역이 게스트 페이지를 넘어서 커널 메모리 맵상 바로 다음 페이지로 넘치게 만드는 것입니다. (그래서 skb linear header를 언급한 것도 좀 헷갈립니다. 그건 완전히 무관한 커널 메모리 영역에 있을 테고, 데이터 포인터만 이들의 데이터를 가리킬 텐데, 그건 제로카피 네트워크 드라이버에서 일어나는 일이죠. KVM 네트워크가 패킷에 대한 게스트의 제어를 유지하도록 그렇게 설정해 뒀을 겁니다.)
악성코드 감염 원인이 LLVM 위협 행위자의 일부인 Clang으로 확인되었습니다. 감염을 제거하려면 Ubuntu에서 /dev와 /proc 디렉터리를 unlink하세요.
맞아요, 최근에 나온 다른 firecracker 탈출( https://www.coinspect.com/blog/firecracker-escape/ )은 io_uring으로 jailer를 뚫었어요. (요약하자면, firecracker는 seccomp로 시스템 콜을 제대로 필터링하고 있었고 자신이 시작한 uring도 필터링했는데, 공격자가 필터링되지 않는 새 uring을 firecracker가 열게 만든 겁니다. 꽤 멋진 방법이죠.)
참고로 말씀드리면 그 탈출은 PwnEscape보다 훨씬 상황을 많이 탑니다. (중첩 KVM에 의존하는 다른 탈출 사례들도 있었고요.) PwnEscape는 사실상 모두가 노출된 것 같아요. Firecracker를 쓰는 사람은 누구나 virtio-net도 쓰니까요.
저는 실제로 네트워크 어댑터 없이 Firecracker를 씁니다. 그래도 vsock/virtio에 남아 있는 문제가 있을 수는 있겠지만요.
그렇죠, 죄송합니다. 제가 말한 건 제공업체였어요. 제공업체는 전부 virtio-net을 씁니다.
Nova 마이크로하이퍼바이저의 접근 방식이 옳다는 확신이 날이 갈수록 강해집니다.
거대하고 복잡하고 깨지기 쉬운 리눅스 커널과 VM 생태계가 하이퍼바이저 계층을 쥐고 흔들게 두지 말고, 형식 검증을 거친 작은 마이크로커널로 가상화를 하고, 리눅스 같은 복잡한 커널은 그 밑에서 돌리자는 거죠.
https://hypervisor.org/
Xen과는 뭐가 다른가요? 하이퍼바이저가 독립된 구성 요소이고, 그 위에서 가상화된 Dom0(Xen 용어) 또는 루트 파티션(Hyper-V 용어)으로 부팅해 아래의 하이퍼바이저를 관리하는, Xen이나 Hyper-V와 같은 접근 방식이잖아요.
하이퍼바이저가 Dom0/루트 파티션 안에서 돌아가는 KVM과는 다른 구조고요.
Xen에서도 며칠 전에 일반적인 게스트-호스트 취약점이 공개됐어요. https://codeant.ai/security-research/xenbleed-a-grant-copy-cache-bug-that-reaches-dom0-memory
네, 결국 보안 설계가 보장하는 수준은 구현만큼입니다. 세상의 온갖 화려한 해싱과 암호화 수학도 잘못된
"*" == "*"검사나 잘못된 참조 검사 앞에서는 아무 소용이 없죠.저는 OP가 Nova가 Xen과 같은 "접근 방식"이라고 한 말에 답한 거였고, 접근 방식을 기준으로 선호를 따진다면 그렇다는 얘기였습니다. 그래도 Nova의 코드베이스가 더 작다고 짚는 건 타당해요. 저한테는 코드베이스가 얼마나 큰가 하는 점이 전반적으로 점점 중요한 기준이 되고 있습니다. 완벽한 보증은 아니지만, 2026년에는 코드베이스가 작다는 것 자체가 긍정적인 신호라고 봅니다.
Nova의 코어는 형식 검증이 되어 있는 것 같은데, 그러면 이번 건을 포함해 Xen에서 생길 수 있는 엄청나게 많은 버그 범주가 배제됩니다.
흥미롭네요. Nova에 대해 더 알아봐야겠습니다.
3mdeb Boot Mastery Conference에서 한 Udo의 최근 발표를 보세요.
인텔 CPU 엔지니어 출신인데, 보안 설계에 대한 사고의 깊이를 보고 제 인생 선택을 되돌아보게 됐습니다.
찾으시는 다른 분들을 위해 올립니다. https://youtu.be/RbL65gVzhNk
감사합니다. 꼭 확인해 보겠습니다.