- V8 샌드박스는 V8 엔진을 위한 경량, 인-프로세스 샌드박스
- 이제 실험단계를 벗어나 Chrome의 취약점 보상 프로그램(VRP)에 포함됨
- 아직 해결해야 할 보안 문제가 있으며, Chrome 123 버전은 샌드박스의 "베타" 릴리스로 간주될 수 있음
동기
- 메모리 안전성은 여전히 중요한 문제로, 지난 3년간 발견된 모든 Chrome 익스플로잇은 V8의 메모리 손상 취약점에서 시작됨
- 이러한 취약점 중 60%는 V8에서 발생했으나, 대부분은 "전형적인" 메모리 손상 버그가 아닌 미묘한 논리 문제임
- 현재 메모리 안전성 솔루션 대부분은 V8에 적용되지 않으며, Rust 같은 메모리 안전 언어로의 전환 또는 메모리 태깅과 같은 하드웨어 기능도 V8의 보안 도전에 도움이 되지 않음
V8 (힙) 샌드박스
- 샌드박스의 기본 아이디어는 V8의 힙 메모리를 격리하여 메모리 손상이 프로세스의 다른 부분으로 "확산"되지 않도록 하는 것
- 하드웨어 지원으로 구현될 수 있지만, 현재 적합한 하드웨어 기능이 없어 소프트웨어 기반으로 구현됨
- 샌드박스는 모든 외부 메모리에 접근할 수 있는 데이터 타입을 "샌드박스 호환" 대안으로 대체함
- 샌드박스 내부의 V8 힙만이 샌드박스 안에 있으며, 이는 WebAssembly의 샌드박싱 모델과 유사
성능
- 샌드박스 접근법의 주요 장점은 기본적으로 비용이 적게 든다는 것
- 샌드박스로 인한 오버헤드는 주로 외부 객체에 대한 포인터 테이블 간접 참조에서 발생하며, 현재 오버헤드는 일반적인 워크로드에서 1% 미만
테스팅
- 보안 경계에 대한 테스트 가능성은 실제로 보안 보장이 실제로 유지되는지 수동 및 자동으로 테스트할 수 있는 능력을 의미함
- V8 샌드박스는 명확한 공격자 모델, 공격자를 모방하는 방법, 보안 경계가 실패했을 때 자동으로 판단하는 방법을 모두 충족함
사용
- V8 샌드박스는 빌드 시간에
v8_enable_sandbox 빌드 플래그를 사용하여 활성화/비활성화해야 함.
- 64비트 시스템에서만 사용 가능하며, 현재 1테라바이트의 가상 주소 공간을 예약해야 함.
- V8 샌드박스는 이미 약 2년 전부터 Android, ChromeOS, Linux, macOS, Windows의 64비트 버전 Chrome에서 기본적으로 활성화됨.
결론
- V8 샌드박스는 프로세스의 다른 메모리에 영향을 미치는 V8의 메모리 손상을 방지하기 위해 설계된 새로운 보안 메커니즘
- 현재의 메모리 안전 기술은 최적화된 JavaScript 엔진에 대부분 적용되지 않지만, V8 샌드박스 공격 표면을 보호하는 데에는 효과적임
- 샌드박스는 메모리 안전성을 향한 필수적인 단계임
GN⁺의 의견
- V8 샌드박스는 메모리 손상 취약점에 대한 현대적인 대응책으로, 기존의 메모리 안전 기술이 해결하지 못하는 문제에 대한 해답을 제공함
- 이 샌드박스는 JavaScript 엔진의 복잡성을 고려할 때, 보안 경계를 더욱 강화하고, 메모리 안전성을 향상시키는 중요한 역할을 함
- 샌드박스의 성능 오버헤드가 낮다는 점은 개발자들에게 매력적일 수 있으며, 이는 샌드박스를 널리 채택하는 데 도움이 될 것임
- 그러나 샌드박스 기술이 완전히 새로운 보안 취약점을 도입할 가능성도 있으며, 이는 지속적인 모니터링과 테스트를 통해 관리되어야 함
- 샌드박스의 효과적인 구현은 공격자가 시스템의 다른 부분으로의 메모리 손상 확산을 방지하는 데 중요한 역할을 하며, 이는 웹 보안을 강화하는 데 기여할 것임