Wasm 샌드박스(Sandbox)의 허점을 파고드는 공격, 당신의 백엔드는 안전한가?
Wasm은 백엔드(Backend) 환경에서 차세대 컨테이너(Next-Generation Container)로 부상했지만, 샌드박스(Sandbox) 취약점이 발견됨
선형 메모리(Linear Memory) 모델의 한계와 JIT 컴파일러(JIT Compiler)의 버그를 악용하여 샌드박스 탈출 시도 가능
AI 모델(AI Model) 실행 환경에서 악성 모델을 통한 공격 위험 증가, 특히 엣지 컴퓨팅(Edge Computing) 환경에서 취약
ISLE 기반의 컴파일러(Compiler) 검증, 힙 샌드박스(Heap Sandbox) 도입, 컴포넌트 모델(Component Model) 등 다중 방어 전략 제시
Wasm 샌드박스(Sandbox)의 구조적 취약점
Wasm은 선형 메모리 모델(Linear Memory Model)을 기반으로 하며, 모든 메모리 접근은 이 메모리 블록 내에서 이루어진다. 하지만, C/C++과 같은 메모리 안전성이 취약한 언어로 작성된 코드는 버퍼 오버플로우(Buffer Overflow)와 같은 취약점에 여전히 노출된다. 특히, Wasm은 스택 카나리(Stack Canary)나 ASLR(Address Space Layout Randomization)과 같은 일반적인 완화 기법을 지원하지 않아, 내부적인 익스플로잇(Exploit)이 더 쉬울 수 있다.
JIT 컴파일러(JIT Compiler)의 취약점
JIT 컴파일러(JIT Compiler)는 Wasm 바이트코드를 네이티브 머신 코드로 변환하여 성능을 향상시키지만, 이 과정에서 발생하는 논리적 오류(Logic Error)는 심각한 보안 문제를 야기할 수 있다. 범위 검사(Bounds Check) 생략과 같은 최적화 과정에서 발생하는 버그는 샌드박스(Sandbox) 탈출의 주요 원인이 된다. 또한, 레지스터 할당(Register Allocation) 과정에서의 오류는 TOCTOU(Time-of-Check to Time-of-Use) 취약점을 발생시킬 수 있다.
실제 사례를 통해 본 Wasm 런타임(Runtime) 공격
2023년 구글 V8 엔진(Google V8 Engine)에서 발생한 타입 혼동(Type Confusion) 취약점은 샌드박스(Sandbox)를 우회하는 데 악용되었다. 공격자는 런타임(Runtime) 내 객체 타입을 혼동시켜, WasmIndirectFunctionTable 내의 포인터를 변조했다. 이로 인해 샌드박스 외부의 임의 메모리 영역에 접근하는 것이 가능해졌다. 2024년 Wasmtime에서도 externref 처리 과정에서 유사한 문제가 발생했다.
AI 모델(AI Model) 실행 환경의 위험성
AI 모델(AI Model)을 엣지(Edge) 환경에서 실행하기 위해 Wasm을 사용하는 경우, 공격 표면이 더욱 넓어진다. 악성 AI 모델 파일은 JIT 컴파일러(JIT Compiler)의 특정 버그를 유발하도록 설계될 수 있으며, 이는 인퍼런스 서버(Inference Server)의 보안을 위협한다. 특히, AI 모델은 데이터와 코드가 혼합된 형태이므로, 모델 자체를 공격 벡터로 활용하는 것이 가능하다.
방어 전략: 다중 계층 보안
샌드박스(Sandbox)의 취약점을 보완하기 위해 다중 계층 보안 모델이 필요하다. ISLE(Instruction Selection Link Edition)을 사용한 컴파일러(Compiler) 검증은 JIT 컴파일러(JIT Compiler)의 논리적 오류를 줄이는 데 기여한다. 구글 V8 엔진(Google V8 Engine)의 힙 샌드박스(Heap Sandbox)는 메모리 손상 시 공격 범위를 제한한다. 또한, 컴포넌트 모델(Component Model)을 통해 애플리케이션을 작은 단위로 분할하여, 한 컴포넌트가 손상되더라도 다른 컴포넌트에 미치는 영향을 최소화할 수 있다.
