Cloudflare Containers에서 다른 고객의 디스크 조각이 보였다 — 원인은 블록 초기화 설정 하나

Cloudflare가 9월 24일 자사 Containers 제품의 교차 테넌트 데이터 노출 취약점을 공개했습니다. 8월에 다룬 Workers Spectre 재현과 성격이 같습니다 — 여러 고객이 한 호스트를 나눠 쓰는 환경에서 격리가 뚫린 사례이고, 이번에는 CPU가 아니라 디스크입니다.

무엇이 문제였나

Containers는 여러 고객의 컨테이너를 같은 호스트에서 돌리고, 디스크는 Linux dm-thin 풀에서 블록 단위로 할당합니다.

• 블록 크기 64KiB, 그리고 skip_block_zeroing 설정이 켜져 있었습니다
• 새 컨테이너가 아직 매핑되지 않은 영역에 4KiB를 쓰면 64KiB 블록 하나가 통째로 할당됩니다
• 그 블록이 이전 컨테이너가 쓰던 물리 블록이면, 나머지 60KiB에 이전 데이터가 그대로 남아 있었습니다

skip_block_zeroing은 성능을 위해 블록 할당 시 0으로 지우는 단계를 건너뛰는 옵션입니다. 단일 테넌트에서는 괜찮지만 멀티테넌트에서는 이전 소유자의 흔적이 넘어갑니다.

타임라인

시각(UTC)
9/4 15:26	Accomplish 보안팀 Oren Yomtov가 HackerOne으로 보고
9/4 18:45	보안 인시던트 개설
9/4 21:27 ~ 23:15	런타임·풀 수정 병합, 배포 시작
9/7 06:13	배포 완료, 기존 풀 데이터 삭제 시작
9/14	연구팀이 PoC가 더는 동작하지 않음을 확인
9/19 15:03	완화 전 캐시 스냅샷까지 완전 삭제

보고부터 수정 배포 시작까지 8시간입니다.

영향

악용하려면 Workers 유료 계정이 필요했습니다. Cloudflare는 과거 디스크 I/O 텔레메트리를 검토해 보고된 기법과 일치하는 활동을 찾지 못했고, 확인된 것은 연구팀과 자사 엔지니어의 검증 활동뿐이라고 밝혔습니다. 영향받은 고객 수나 노출 가능했던 데이터 규모는 글에 없습니다.

조치

skip_block_zeroing 제거(기본 동작 복원), 기존 컨테이너 디스크 폐기, 완화 전 캐시된 OCI 이미지 레이어 스냅샷 전부 삭제, 호스트 드레인과 VM 재시작. 고객이 할 일은 없습니다.

실무에서 할 일

Containers 사용자는 할 게 없습니다. 더 넓게는 — 자체 인프라에서 dm-thin이나 비슷한 씬 프로비저닝을 멀티테넌트로 쓰고 있다면 블록 초기화 설정을 한 번 확인할 가치가 있습니다. 성능 옵션 하나가 격리 경계였던 사례입니다.