클라우드플레어의 컨테이너 격리가 고객 사이에서 새고 있었다. 가장 곤란한 쪽은 AI 에이전트용으로 파는 제품이다

클라우드플레어가 9월 24일, 자사 Containers 플랫폼의 결함에 대한 사후 분석을 공개했다. 한 고객의 워크로드가 다른 고객의 워크로드가 남긴 디스크 데이터를 읽을 수 있었던 문제다. 회사는 이 문제가 완전히 해결됐으며, 과거 디스크 I/O 텔레메트리를 검토한 결과 제보한 연구자와 자사 엔지니어 외에 누군가 이를 사용한 증거는 없다고 밝혔다. 공개 내용은 이례적으로 상세하고, 대응은 이례적으로 빨랐다. 그렇다고 결함의 성격이 달라지지는 않는다. 이 제품이 팔리는 근거 자체인 경계가 무너진 것이다.

무엇이 잘못됐나

Containers와 그 위에 얹은 Sandboxes는 고객 워크로드를 씬 프로비저닝 스토리지가 받치는 공유 호스트에서 돌린다. 디스크 공간은 워크로드가 쓰는 만큼 64 KiB 블록 단위로 배정되고, 워크로드가 파기되면 공유 풀로 반납된다. 클라우드플레어는 블록을 다음 사용자에게 넘기기 전에 0으로 채우는 스토리지 계층의 기본 동작을 꺼둔 상태였다. dm-thin 풀의 skip_block_zeroing 설정으로, 성능을 위한 선택이었다. 그 결과 블록은 앞선 사용자가 써둔 내용을 그대로 담은 채 새 컨테이너에 도달할 수 있었다.

이것이 만들어내는 것은 실시간 접근이 아니라 잔여 데이터 노출이다. 클라우드플레어의 설명은 한계에 대해서도 구체적이다. 공격자는 피해자를 지목할 수 없었고, 실행 중인 워크로드에 붙어 있는 디스크를 읽을 수 없었으며, 다른 고객의 데이터를 수정하거나 가용성에 영향을 줄 수도 없었다. 돌아올 수 있었던 것은 같은 호스트에서 그 블록을 앞서 점유했던 누군가의 파일시스템 메타데이터, 디렉터리 구조, 데이터베이스 페이지, 그리고 애플리케이션 데이터였다.

규모는 어느 정도였나

클라우드플레어의 해커원(HackerOne) 프로그램을 통해 제보한 Accomplish의 오렌 욤토브(Oren Yomtov)는 범위를 구체적으로 보여주는 측정치를 공개했다. 타 테넌트의 잔여 데이터는 네 개 대륙에 걸친 컨테이너 배치 24건 중 18건에서, 그리고 기반 머신 22대 중 20대에서 확인됐다. 검사 가능한 디렉터리 블록 5,614개 중 다른 테넌트에 속한 서로 다른 디렉터리 inode 약 2,700개가 식별됐고, 구조적으로 온전한 SQLite 데이터베이스도 나왔다.

운 나쁜 할당이 빚어낸 좁은 예외 사례가 아니다. 플랫폼의 평상시 동작이다.

Sandboxes가 특히 불편한 이유

Containers는 인프라다. 그 위에서 클라우드플레어가 파는 것이 Sandboxes이고, 문서는 용도를 분명히 적어두었다. 대규모 언어 모델이 생성한 코드의 실행, 그리고 "신뢰할 수 없는 코드를 실행해야 하는 AI 에이전트, 코드 어시스턴트, 자율 시스템"이다.

그 일을 하는 동안 작동 중인 에이전트가 디스크에 무엇을 남기는지 생각해보라. 체크아웃한 저장소. .env 파일. 하위 프로세스가 읽을 수 있도록 어딘가에 써둔 단명 API 토큰. 에이전트가 무엇을 하고 있었는지의 기록을 담은 SQLite 상태. 에이전트가 쓸모 있으려면 필요한 산출물의 범주는, 재활용되는 블록에 남겨두면 가장 곤란한 것들의 범주와 정확히 겹친다. 샌드박스란 신뢰하지 않기로 한 코드 주위에 그은 경계선이다. 제품의 가치는 전적으로 그 경계가 유지되는 데 달려 있다.

고객이 실제로 할 수 있는 일

패치라는 의미에서는 없다. CVE도, 옮겨갈 버전도, 관련된 고객 측 설정도 없다. 수정은 서버 측에서 이루어졌고 이미 전 기종에 배포됐다.

진짜 문제는 자격 증명이며, 이는 지시가 아니라 판단의 영역이다. 클라우드플레어의 텔레메트리 검토가 입증하는 것은 이 특정 기법이 다른 사람들에 의해 사용되지 않았다는 사실이다. 9월 7일 이전에 Container나 Sandbox 안에 있었던 어떤 비밀도 목격되지 않았다는 것까지 입증하지는 않으며, 그럴 수도 없다. 그 워크로드 안에 장기 유효 자격 증명을 두고 있던 조직이라면 교체 비용과 견주어 판단해야 한다. 빈약한 답이지만, 그것이 잔여 데이터 노출이라는 사건의 본질이다. 피해자 자신의 로그에는 찾아볼 것이 아무것도 남지 않는다.

인정할 부분, 그리고 그 아래의 거래

이 타임라인은 소리 내어 말할 가치가 있다. 제보에서 운영 환경 확인까지 3시간 19분. 제보에서 수정 머지까지 6시간. 배포는 같은 날 시작됐다. 이렇게 빨리 제보를 인정하는 벤더는 많지 않다. 게다가 위험한 동작이 실수가 아니라 의도적인 성능 설정이었다고 인정하면서 작동 원리를 공개한 것은, 공개 관행이 요구하는 수준을 한참 넘어선다.

대응이 좋았다고 해서 더 큰 논점이 사라지지는 않는다. 업계는 지난 2년 동안 신뢰할 수 없는 코드의 실행을 고객 자신의 장비에서 공유형 멀티테넌트 플랫폼으로 옮겨왔다. 에이전트에게는 싸고 즉시 돌아가는 자리가 필요하기 때문이다. 이 거래가 사는 것은 속도와 비용이고, 파는 것은 격리가 모든 계층에서 유지된다는 가정이다. 아무도 마케팅하지 않는 블록 할당 같은 밋밋한 계층까지 포함해서다. 이번에 격리는 스토리지 풀을 제외한 모든 곳에서 유지됐다.

출처: Cloudflare Blog · The Hacker News · Cyber Security News · GBHackers · Cloudflare Sandbox SDK 문서