hyunsu blog

홈동향

PwnEscape 리눅스 VM 탈출, 고칠 곳은 게스트가 아닌 호스트 커널

목차 · 8
  1. 01백만 달러 샌드박스 챌린지 사흘째에 18년 된 커널 결함이 나왔다
  2. 02체크섬을 '나중에 채우라'는 정보를 믿어, 검사를 마친 헤더가 뒤에서 바뀐다
  3. 03점수는 9.3과 8.8로 갈리지만, 우회책이 없다는 판단은 같다
  4. 04배포판마다 고친 커널이 닿은 시점이 다르다
  5. 05호스트에서 확인하고 올리는 순서
  6. 06한국 개발자에게: 남의 코드가 도는 호스트부터 손댄다
  7. 07고친 뒤에도 후속 수정과 피해 반경 줄이기가 남는다
  8. 08자주 묻는 질문

PwnEscape 는 어디를 고쳐야 막히나? 게스트가 아닌 호스트 커널이다. 18년 묵은 IPv4 체크섬 처리 결함(CVE-2026-99999)이라 공식 우회책이 없고, virtio-net 으로 VM 을 돌리는 호스트는 고친 커널을 깔고 재부팅해야 한다.

01 백만 달러 샌드박스 챌린지 사흘째에 18년 된 커널 결함이 나왔다

Vercel 은 2026년 8월 HackerOne 에서 자사 코드 실행 환경인 Vercel Sandbox 를 뚫어 보라는 공개 챌린지를 열었다. 상금 한도는 100만 달러였다. 이 샌드박스는 샌드박스마다 전용 게스트 커널을 단 Firecracker 마이크로 VM 을 하나씩 띄운다. Firecracker 는 KVM 위에서 작은 VM 을 띄우는 VMM(가상 머신 관리자)이다. 10월 14일 Vercel 이 낸 회고에 실린 결과는 이렇다.

항목결과
접수된 보고1,285건
유효 판정57건(이 중 Critical 1건)
지급한 상금242,000달러
고객 데이터에 닿은 보고없음

유일한 Critical 이 PwnEscape 다. pwn.ai 의 연구자가 특별한 권한 없는 일반 샌드박스에서 출발해, 챌린지 사흘째에 호스트 메모리가 새는 현상을 보고했다. 원인을 따라가 보니 Vercel 의 설정 실수가 아니라 리눅스 커널 네트워크 스택이 문제였다. 메모리 유출은 Vercel 운영 샌드박스에서 실제로 재현됐고, 호스트를 멈추거나 호스트 root 로 명령을 돌리는 단계는 연구자의 KVM·Firecracker 실험 환경에서만 확인됐다.

뿌리는 깊다. CVE 레코드는 tun 장치가 virtio-net 헤더로 GSO(큰 패킷을 나중에 쪼개 보내는 오프로드)를 받도록 한 커밋을 결함의 출발점으로 잡고, 첫 영향 버전으로 2.6 계열 커널을 적었다. 그 커널이 나온 때가 2008년 10월이다. 그 뒤 18년 동안 같은 코드가 리눅스 호스트 커널에 남아 있었던 셈이다.

02 체크섬을 '나중에 채우라'는 정보를 믿어, 검사를 마친 헤더가 뒤에서 바뀐다

이름과 달리 결함은 KVM 에 있지 않다. AlmaLinux 공지가 짚듯 호스트 커널의 IPv4 스택에 있고, 흐름을 따라가려면 체크섬 오프로드부터 알아야 한다.

리눅스는 내보낼 패킷의 체크섬을 바로 계산하지 않고 CHECKSUM_PARTIAL 표시만 붙여 둘 수 있다. 이때 csum_start(계산을 시작할 위치)와 csum_offset(그 위치에서 결과를 적을 칸까지의 거리)이 함께 실린다. 장치가 그 체크섬을 맡지 못하는 경로에서는 커널이 skb_checksum_help() 로 직접 계산해 그 칸에 값을 적는다. 가상 네트워크에서는 이 위치 정보를 게스트가 virtio-net 헤더에 담아 보낸다.

text
1. 게스트 VM    프레임 + virtio-net 헤더(체크섬 시작 위치·결과 칸)를 보낸다
2. VMM          TAP·vhost-net 으로 호스트 커널에 넘긴다
3. 호스트 IPv4  IPv4 헤더를 읽고 검사한 뒤 그 값으로 다음 처리를 정한다    ← 검사 시점
4. 체크섬 보완  skb_checksum_help() 가 소프트웨어로 체크섬을 적는다
                시작 위치가 IPv4 헤더 안쪽이면 검사가 끝난 바이트를 덮는다 ← 사용 시점
5. 그 뒤        이미 내린 판단과 실제 헤더가 어긋나 경계 밖 커널 메모리가 새거나 깨진다

검사한 때(time of check)와 그 값을 쓰는 때(time of use) 사이에 데이터가 바뀌는 TOCTOU 결함이다. 다른 점은 값을 바꾸는 쪽이 다른 스레드가 아니라 커널 자신의 체크섬 코드이고, 어디를 덮을지는 게스트가 고른다는 것이다. AWS 는 게스트 안의 권한 있는 사용자를 공격 주체로 봤다. VPS·샌드박스 고객은 대개 자기 VM 의 root 이니, 남에게 VM 을 내주는 호스트라면 고객 누구나 그 조건을 갖춘 셈이다.

고친 커밋 6785011f8b16("ipv4: validate checksum_start before completing checksum")은 Red Hat 의 커널 개발자가 썼고, 10월 14일 메인라인에 들어갔다. 새로 생긴 ip_check_csum_start() 는 체크섬 시작 위치가 IPv4 헤더 안을 가리키면 오류를 돌려준다. 호출하는 쪽은 그런 패킷에 skb_checksum_help() 를 부르지 않는다. 손댄 곳은 IPv4 출력, IPsec(xfrm) 출력, netfilter 의 CHECKSUM 타깃과 패킷 큐, 브리지 연결 추적, 그리고 새 함수를 선언한 헤더까지 여섯 파일이다. 바뀐 줄은 다 합쳐 56줄 남짓으로 작다.

커밋의 Fixes 태그는 두 커밋을 가리킨다. 하나는 앞의 tun 커밋이고, 다른 하나는 패킷 소켓(AF_PACKET)에 체크섬 오프로드를 넣은 커밋이다. VM 이 없어도 같은 메타데이터가 커널에 들어올 길이 있다는 뜻이고, AlmaLinux 도 로컬 사용자가 결함을 건드릴 수 있다고 적었다.

03 점수는 9.3과 8.8로 갈리지만, 우회책이 없다는 판단은 같다

평가한 곳점수·등급벡터의 권한 요구(PR)
Linux 커널 CNA(CVE 레코드)CVSS 3.1 9.3, Critical없음(N)
Red HatCVSS 3.1 8.8, Important낮음(L)
Ubuntu우선순위 Medium(CVSS 9.3 함께 표시)없음(N)
AWS 보안 공지Important—

두 CVSS 벡터는 권한 요구 한 칸만 다르다. 게스트 안에서 권한이 필요하다고 보느냐에 따라 0.5점이 갈린 셈이다. Ubuntu 는 9.3 을 함께 띄우면서도 자체 우선순위를 Medium 으로 뒀으니, 우선순위 칸만 보고 일정을 미루지 않는 편이 낫다.

등급과 상관없이 결론은 같다. AWS 와 Red Hat 은 쓸 만한 임시 완화책이 없다고 밝혔고, AlmaLinux 는 고친 커널이 곧 해결책이라고 적었다. 커널은 재부팅해야 바뀌는데, 가상화 호스트를 재부팅하면 그 위 VM 이 모두 멈춘다. 그래서 AlmaLinux 는 VM 을 다른 호스트로 옮기거나 내린 뒤 재부팅하라고 권한다.

공개까지의 흐름도 볼 만하다. 패치는 9월 하순 공개 메일링 리스트에 올라왔는데 CVE 는 10월 중순에 나왔고, 배포판 커널은 그보다 더 늦다.

날짜(2026)일
8월 18일Vercel 챌린지 발표
8월 20일호스트 메모리 유출 첫 보고
9월 4일근본 원인을 커널 보안 담당·네트워크 메인테이너에 비공개 전달
9월 19~22일netdev 메일링 리스트에 패치 공개 제출
9월 25일CVE 번호 예약
10월 14일메인라인 병합
10월 15일CVE 공개(Linux CNA), AWS 보안 공지
10월 16일AlmaLinux 테스트 커널, 사쿠라 인터넷 VPS 신규 접수 중단

04 배포판마다 고친 커널이 닿은 시점이 다르다

upstream 은 지원 중인 안정판 계열마다 수정을 넣었다. 그러나 배포판 커널은 백포트에 자체 번호를 붙이므로, uname -r 결과를 upstream 번호와 바로 견주면 판단이 틀린다. 아래는 2026년 10월 19일에 각 공지를 열어 본 상태다. 정확한 고친 버전은 표의 각 공지에서 확인한다.

대상상태확인한 곳
upstream 안정판5.10·5.15·6.1·6.6·6.12·6.18·7.2 계열 모두 반영CVE 레코드
Debian 12·13보안 저장소에 고친 커널(DLA-4841-1, DSA-6568-1)Debian 보안 추적기
Ubuntu 20.04~26.04 LTSlinux 패키지 Needs evaluation, 고친 버전 없음Ubuntu CVE 페이지
RHEL 8·9·10추적 중인 전 제품 영향, 고친 패키지 없음Red Hat CVE 페이지
AlmaLinux 8·9·10almalinux-testing 저장소에만 있음AlmaLinux 블로그
Rocky Linux 9·10안정 저장소 보안 메타데이터에 수정 없음(10월 18일)VirtFusion 문서
Amazon Linux 2·2023고친 커널 공개AWS 보안 공지

05 호스트에서 확인하고 올리는 순서

  1. 남의 VM 을 virtio-net(TAP·vhost-net)으로 붙이는 KVM 호스트와 Firecracker 샌드박스 호스트부터 목록을 만든다.
  2. 호스트마다 설치된 커널 패키지를 배포판 공지의 고친 버전과 맞춰 본다.
  3. 고친 커널이 나온 배포판이면 설치하고, 아직이면 공지를 지켜본다.
  4. VM 을 옮기거나 내리고 재부팅 창을 잡는다.
  5. 재부팅 뒤 실행 중인 커널이 고친 버전인지 다시 확인한다.
  6. 라이브 패치로 버틸 생각이면 그 패치가 이 CVE 를 덮는지 제공사에 먼저 묻는다.

RHEL 계열은 저장소에 이 CVE 를 고친 공지가 올라왔는지부터 본다. dnf 의 --cve 옵션은 해당 CVE 를 고치는 패키지만 골라 보여 준다.

bash
uname -r
rpm -q kernel
sudo dnf --refresh updateinfo info --cve=CVE-2026-99999

AlmaLinux 는 테스트 저장소의 커널을 먼저 시험해 달라고 요청했다. 검증용 호스트에서만 이렇게 올리고, 끝나면 테스트 저장소를 끈다.

bash
sudo dnf install -y almalinux-release-testing
sudo dnf update 'kernel*' --enablerepo=almalinux-testing
sudo reboot
# 재부팅 뒤 uname -r 로 확인하고, 운영 호스트에선 테스트 저장소를 끈다
sudo dnf config-manager --disable almalinux-testing

Debian 12·13 은 보안 저장소의 커널을 받으면 된다.

bash
sudo apt-get update
sudo apt-get install "linux-image-$(dpkg --print-architecture)"
sudo reboot
# 재부팅 뒤
uname -r
dpkg-query -W "linux-image-$(uname -r)"

Ubuntu 는 아직 고친 패키지가 없다. CVE 페이지의 상태가 바뀌면 평소처럼 커널을 올리고 재부팅하면 된다.

06 한국 개발자에게: 남의 코드가 도는 호스트부터 손댄다

가장 급한 쪽은 KVM·Firecracker 로 VPS·클라우드·코드 실행 샌드박스를 내주는 사업자다. 사내라도 개발용 VM 이나 CI 러너 VM 을 여러 팀에 나눠 주는 가상화 호스트라면 같은 무게로 본다. 게스트 쪽 사용자를 다 믿을 수 없다면 이번 주 안에 위 순서를 밟고 재부팅 일정을 공지하는 것이 맞다.

배포판 수정이 아직인 Ubuntu·RHEL 호스트라면, 기다리는 동안 새 VM 접수를 늦추는 선택지도 있다. 일본 사쿠라 인터넷이 실제로 그렇게 했다. 10월 16일부터 이시카리·도쿄·오사카 전 리전에서 VPS 신규 신청을 막았고, 스케일업·고객 ISO 설치·클라우드 이전 기능도 멈췄다. 이미 돌고 있는 VM 은 그대로 뒀다.

클라우드 VM 을 빌려 쓰는 대다수 웹·앱 개발자는 직접 할 일이 적다. 게스트 커널을 올려도 이 결함은 막히지 않고, 호스트는 사업자 몫이다. AWS 는 EC2·Lambda·Fargate 가 영향을 받지 않는다고 밝혔지만, 국내 사업자의 공지는 10월 19일에 찾아본 범위에서 보지 못했다. 쓰는 사업자에 CVE 번호를 대고 호스트 패치 여부와 정비 일정을 물어 두면 된다. 정비 중에는 사쿠라처럼 신규 생성이나 스케일업이 막힐 수 있으니, 가까운 증설 계획이 있다면 함께 확인한다.

예외가 하나 있다. 빌린 VM 안에서 다시 KVM 이나 Firecracker 를 돌리면 그 VM 이 곧 호스트다. AWS 도 Firecracker 같은 VMM 으로 직접 돌리는 VM 은 영향권이라며, 그 호스트 커널을 고치고 재부팅하라고 안내했다. AI 에이전트용 코드 실행 환경을 직접 꾸린 팀이 여기에 든다.

VM 이 없는 일반 리눅스 서버는 급도가 한 단계 낮다. AlmaLinux 가 가장 위험한 곳으로 꼽은 것은 믿을 수 없는 게스트를 돌리는 가상화 호스트였다. 다만 로컬 사용자 경로도 열려 있으니 다음 정기 커널 업데이트에 함께 넣고, 여러 사람이 셸을 쓰는 공용 서버라면 그 일정을 앞당긴다.

07 고친 뒤에도 후속 수정과 피해 반경 줄이기가 남는다

이번 커밋은 끝이 아니다. 커밋 메시지와 CVE 레코드 모두 이 수정을 심층 방어(defense in depth) 수준이라고 적었고, 입력 단계에서 체크섬 메타데이터를 제대로 거르는 검증은 아직 준비 중이라고 밝혔다. pwn.ai 는 별개의 네트워크 탈출 결함을 따로 찾아 다음 글에서 다루겠다고 했다. 정책 검사가 끝난 뒤 전송 계층 필드가 바뀌는 문제도 이번 IPv4 수정으로는 막히지 않는다고 짚었다. 같은 경로에서 후속 수정이 이어질 수 있으니 커널 보안 공지를 계속 지켜본다.

Vercel 은 결함이 다시 나와도 피해를 좁히는 쪽에 힘을 줬다. 자체 샌드박스를 돌리는 팀이 그대로 가져올 만한 항목이다.

  • 호스트 커널을 최신으로 유지하고, 중첩 가상화를 끈다.
  • Firecracker jailer 로 마이크로 VM 프로세스마다 권한을 좁히고 호스트의 나머지와 떼어 놓는다.
  • 샌드박스마다 전용 게스트 커널을 두고, 장치 모델을 최소로 줄인다.
  • 게스트에서 제어 영역으로 넘어오는 값은 서버 쪽에서 다시 만들거나, 게스트가 볼 수 없는 키로 서명한다.

이번 결함 자체가 게스트가 준 값을 호스트가 믿어서 생겼다. 마지막 항목이 커널 밖 설계에도 그대로 들어맞는 이유다.

08 자주 묻는 질문

CVE-2026-99999 는 임시 번호인가

아니다. Linux 커널 CNA 가 9월 25일 예약하고 10월 15일 공개한 정식 레코드다. 배포판 추적기와 AWS 보안 공지도 같은 번호를 쓴다.

게스트 VM 커널만 올리면 되나

아니다. 결함은 게스트가 보낸 체크섬 정보를 처리하는 호스트 커널에 있다. 빌려 쓰는 VM 이라면 사업자의 호스트 패치 여부를 확인해야 한다.

재부팅 없이 막을 수 있나

아니다. AWS·Red Hat 모두 쓸 만한 임시 완화책이 없다고 했고, 커널은 재부팅 뒤에 바뀐다. 라이브 패치를 쓴다면 이 CVE 를 덮는지 제공사에 먼저 확인한다.

VM 을 돌리지 않는 서버도 고쳐야 하나

예, 다만 순서는 뒤다. 로컬 사용자도 결함을 건드릴 수 있어 다음 정기 커널 업데이트에 함께 넣고, 공용 셸 서버는 앞당긴다.