클라우드플레어(Cloudflare)가 자사의 서버리스 실행 환경인 Workers를 겨냥한 원격 Spectre 공격을 2024년과 2025년에 걸쳐 다시 평가한 결과를 논문과 함께 공개했다. 회사는 2021년에도 동일한 위협을 한 차례 검증하고 그 결과로 '동적 프로세스 격리(Dynamic Process Isolation, DyPrIs)'라는 방어책을 프로덕션에 투입한 바 있다. 이후 Spectre 공격을 안정화하는 새로운 기법들이 학계와 업계에서 등장하면서, 이 기법들이 실제 운영 환경을 위협할 수 있는지 내부적으로 재검증할 필요가 생겼다. 결론부터 말하면, 연구팀은 프로덕션 환경에서 초당 최대 12비트를 99% 정확도로 안정적으로 유출하는 원격 Spectre 공격을 실증했고, 그 과정에서 DyPrIs 구현의 한계를 발견했다. 다만 이 공격은 이미 방어책으로 완화된 상태이며, 지난 3년간 실제 악용 흔적은 발견되지 않았다고 밝혔다.
왜 Workers가 특히 까다로운가
Workers는 신뢰할 수 없는 자바스크립트를 엣지에서 실행하는 구조다. V8 아이솔레이트(isolate)라는 언어 수준의 격리를 활용해 수만 개의 테넌트가 하나의 운영체제 프로세스를 공유하도록 설계됐다. 각 Worker는 별도의 자바스크립트 힙을 갖는다. 이 방식은 시작 지연을 낮추고 완전한 프로세스 격리보다 훨씬 효율적으로 다수의 테넌트를 수용할 수 있게 해준다. 문제는 이 구조가 Spectre 계열 공격에 근본적으로 취약하다는 점이다. Spectre는 CPU의 투기적 실행(speculative execution)을 악용한다. CPU는 분기의 결과를 미리 예측해 명령을 앞당겨 실행하는데, 예측이 틀리면 결과를 폐기하고 되돌린다. 그러나 이 일시적(transient) 명령들이 남긴 흔적은 CPU 캐시 같은 마이크로아키텍처 상태에 남는다. 공격자는 이를 이용해 경계 밖 메모리를 투기적으로 읽고, 그 값의 한 비트를 캐시 상태로 인코딩한 뒤, 재접근 지연시간을 측정해 비트 값을 추론한다. 프로세스를 공유하는 구조에서는 단 하나의 임의 읽기 취약점이 테넌트 간 정보 유출로 이어질 수 있다.
프로덕션에서 공격을 성립시키는 조건들
실험실이 아닌 실제 운영 환경에서 부채널 공격을 성공시키려면 여러 장애물을 넘어야 한다. 공유 하드웨어의 활동, 인터럽트, 문맥 전환, 그리고 무엇보다 거친(coarse-grained) 타이머가 방해가 된다. Workers는 의도적으로 타이머를 제한한다. CPU 연산 중에는 시간이 사실상 정지되며 Date.now()나 performance.now()도 연속적으로 증가하는 고해상도 시계를 제공하지 않는다. 공유 메모리와 멀티스레딩이 없으므로 SharedArrayBuffer를 이용한 고전적인 카운터 스레드 타이머도 쓸 수 없다. 연구팀은 이 제약을 우회하기 위해 외부 서버로 향하는 웹소켓 연결을 원격 타이머로 활용했다. Worker가 특정 이벤트의 시작과 종료 시점에 원격 서버에 타임스탬프를 요청하고 그 차이를 계산하는 방식이다. 여러 타이머 구성을 평가한 결과, 위상적으로 먼 거리에서도 소수의 샘플만으로 중앙값 기준 밀리초 이하 해상도를 안정적으로 얻을 수 있었다.
원격 타이머의 잡음은 캐시 히트와 미스의 수 나노초 차이를 그대로 구분하기에는 너무 크다. 그래서 신호 증폭이 필요하다. 연구팀은 스티븐 뢰트거와 아르투르 얀츠가 발견한 기법, 즉 L1 캐시의 트리 기반 의사 LRU(PLRU) 교체 정책을 악용하는 방식을 이용했다. 이 정책은 각 캐시 세트를 이진 트리로 구성하는데, 적절한 접근 패턴으로 대상 라인의 트리 이웃을 건드리면 그 라인을 무한정 캐시에 유지하거나 반대로 대량의 미스를 유발할 수 있다. 단일 캐시 이벤트의 타이밍을 임의로 증폭할 수 있어, 잡음이 많은 원격 타이머로도 인코딩된 비트를 구별하게 된다.
Spectre 가젯과 캐시 축출
공격에는 두 종류의 Spectre 가젯이 쓰였다. 하나는 아이솔레이트 힙의 기준 주소 같은 압축된 힙 포인터를 유출하고, 다른 하나는 투기적 타입 혼동(type confusion)을 이용해 공격자가 조작한 임의의 64비트 포인터에서 값을 읽어낸다. 연구 당시 Workers에는 V8 Sandbox가 아직 적용되지 않았다. 포인터 압축 하에서 대부분의 객체는 32비트 압축 포인터를 쓰지만, TypedArray는 예외적으로 백킹 스토어를 가리키는 원시 64비트 포인터를 보관했고, 가젯은 바로 이 점을 파고들었다. instanceof 타입 검사 분기를 실제 객체로 반복 호출해 분기 예측을 오훈련시킨 뒤, 메모리 배치가 다른 객체를 넘기면 CPU가 잘못된 타입의 포인터를 투기적으로 따라간다. 이를 통해 임의 주소 읽기로 확장할 수 있었다.
측정을 반복하려면 매 라운드마다 캐시 상태를 초기화해야 한다. 분기가 의존하는 값과 유출 비트를 인코딩하는 프로브 라인 모두 캐시에서 비워져 있어야 한다. 정밀한 축출 집합(eviction set)을 만드는 고전적 방법은 많은 타이밍 측정을 요구해 잡음 많은 원격 타이머에는 비효율적이다. 연구팀은 두걸 존슨이 소개한 더 우아한 접근을 택했다. 비둘기집 원리에 따라 캐시 용량보다 훨씬 큰 데이터를 할당해두면 무작위로 고른 캐시 라인은 거의 확실히 이미 축출된 상태다. 예컨대 256KB L2 캐시에 대해 64MB를 할당하면 임의 라인이 여전히 캐시에 남아 있을 확률은 최대 256분의 1에 불과하다. 특정 라인을 축출하는 대신, 이미 비워져 있을 새 무작위 위치를 고르는 것이다.
공동 배치와 실무적 의미
공격이 성립하려면 공격자와 피해자 아이솔레이트가 같은 엣지 서버의 같은 프로세스에 스케줄링되어야 한다. 클라우드플레어가 수만 대의 엣지 서버를 운영한다는 점을 생각하면 어려워 보이지만, 실제로는 놀라울 만큼 간단하다. Workers는 어느 엣지 서버에서든 실행되도록 설계됐기 때문에, 공격 스크립트에서 fetch("https://victim.example")로 피해자 스크립트를 호출하면 대개 스케줄러가 같은 프로세스에 피해자 Worker 인스턴스를 띄운다. 일정 간격으로 하위 요청을 계속 보내면 피해자 아이솔레이트를 살려둘 수도 있다.
이번 연구의 결과로 클라우드플레어는 DyPrIs를 개선하고 V8 Sandbox와 인프로세스 격리 메커니즘을 통합해 메모리 유출 위험을 추가로 낮췄다. 실무자 관점에서 이 사례가 주는 시사점은 분명하다. 언어 수준 격리를 통한 멀티테넌시는 성능과 밀도에서 이점이 크지만, 하드웨어 마이크로아키텍처를 공유하는 한 투기적 실행 부채널은 순수 소프트웨어 방어만으로 완전히 봉쇄하기 어렵다. 타이머를 제한하고 공유 메모리를 제거해도, 원격 타이머와 PLRU 증폭 같은 우회 기법이 조합되면 프로덕션의 잡음 속에서도 유의미한 대역폭의 유출이 가능하다는 점을 이번 실증이 보여준다. 초당 12비트라는 유출 속도는 대량의 비밀을 즉시 빼내기에는 느리지만, 안정적이고 재현 가능하다는 사실 자체가 방어를 다층적으로 쌓아야 하는 이유가 된다. 12비트라는 수치와 99% 정확도, 그리고 악용 흔적이 없었다는 점을 함께 놓고 보면, 이는 위협이 현실이 되기 전에 선제적으로 방어를 강화한 방어적 연구의 사례로 읽힌다.