LANTERN: WebGPU 규격 기반 변이 테스트로 브라우저 상태 기계 결함 찾기

• 원문: LANTERN: Specification-Guided Mutation Testing for WebGPU
• 저자: Mahya Samdaliri, Zhihao Yao, Kasthuri Jayarajah
• 공개일: 2026-09-22
• 버전: arXiv:2609.25520v1, 14쪽
• Tags: WebGPU, Chromium, browser security, fuzzing, mutation testing, specification, CTS, GPU process, memory safety, LANTERN

본 글은 원 논문의 주요 기술적 내용을 이해하기 쉽게 요약·정리한 글입니다. 자세한 내용은 상단의 원문 링크를 참고하세요.

한눈에 보기

LANTERN은 WebGPU Conformance Test Suite를 seed로 삼고, WebIDL의 명시 규칙과 규격 문맥의 암묵적 lifecycle·ordering 규칙을 추출해 JavaScript 테스트를 변이하는 도구입니다. 무작위 바이트 변이보다 깊은 WebGPU 상태에 도달하면서, 정적 CTS가 놓치는 객체 수명·호출 순서·정렬 조건의 조합을 탐색하려는 접근입니다.

Chromium 146 ASan+DCHECK 빌드에서 scale과 valid/invalid 방향을 바꿔 약 15시간씩 실행했고, 7개 crash 중 3개를 재현했습니다. 하나는 V8 ThreadIsolation allocator의 bad free, 하나는 Skia font 경로 DCHECK, 하나는 Mojo direct receiver DCHECK였습니다. 다만 V8 건은 비공개 기존 이슈의 중복으로 판정되었고, 나머지는 exploitability나 WebGPU와의 인과관계가 완전히 입증되지 않았습니다.

연구 배경

WebGPU는 JavaScript에서 GPU 명령, buffer, texture, pipeline을 다루게 하며 브라우저 renderer, IPC, GPU process, 그래픽 드라이버를 가로지릅니다. 공식 CTS는 규격 준수에 강하지만 개별 요구사항을 비교적 고립된 테스트로 검증하고, 일반 fuzzer는 많은 입력을 얕은 validation에서 잃거나 multi-process crash feedback을 얻기 어렵습니다.

LANTERN은 이미 well-formed한 CTS 프로그램의 AST와 규격 기반 전제조건을 이용합니다. 목표는 무작위 API 호출을 생성하는 것이 아니라, 기존 테스트가 가진 깊은 초기화와 객체 관계를 유지하면서 규격상 유효하거나 의도적으로 한 조건만 어기는 변형을 만드는 것입니다.

공격 모델 / 전제 조건

위협 모델은 피해자가 공격자 통제 웹페이지나 iframe을 Chromium 계열 브라우저에서 열고 WebGPU 실행을 허용하는 원격 웹 공격입니다. 공격자는 JavaScript와 WebGPU 명령을 통제하지만 로컬 파일, 물리 장치, side channel, 브라우저 프로세스 권한을 초기에는 갖지 않습니다.

성공적인 보안 영향에는 입력이 renderer의 WebGPU binding과 Dawn·GPU process·드라이버 경로에 도달하고, validation이 막지 못한 메모리 안전성 또는 신뢰 경계 오류가 발생해야 합니다. 연구의 crash는 controlled victim 환경의 instrumented 브라우저에서 얻었으며, sandbox 탈출·임의 코드 실행·실사용자 공격은 입증하지 않았습니다.

비판적 검토 / 아쉬운 점

가장 큰 한계는 “고유 로그 출력 source location”을 coverage 대리 지표로 사용했다는 점입니다. 로그가 없는 실행 경로를 놓치고, 한 위치가 여러 의미 상태를 대표할 수 있어 195개 위치가 곧 넓은 code coverage를 뜻하지 않습니다. Sanitizer coverage나 edge coverage와 함께 비교해야 탐색 우위를 정확히 평가할 수 있습니다.

두 번째로 7개 crash 중 4개가 재현되지 않았고, 재현된 3개 중 V8 건은 기존 비공개 이슈의 중복이며 Mojo 건은 WebGPU 의존성과 보안 영향이 확정되지 않았습니다. “WebGPU 취약점 7개 발견”보다 “7개 신호, 3개 재현, 그중 최소 1개는 기존 결함의 새 trigger”가 정확합니다. 최소화된 testcase, 반복 재현률, triage 결과 공개가 보완되어야 합니다.

세 번째로 implicit rule은 GPT-5가 제안한 뒤 사람이 검토했지만 규칙 완전성과 reviewer 간 일치도를 제시하지 않습니다. Chromium/Dawn 한 구현과 두 버전만 평가했으므로 Firefox, Safari, wgpu-native, 드라이버별 일반화도 아직 증명되지 않았습니다.

핵심 Root Cause

WebGPU의 보안 불변조건은 API validation을 통과한 객체와 명령의 의미가 renderer, IPC, GPU service, 그래픽 backend 전반에서 동일하게 보존되고, 객체 lifecycle·호출 순서·정렬·크기가 어떤 긴 조합에서도 안전해야 한다는 것입니다. 정적 CTS와 얕은 fuzzer는 이 상태 공간을 충분히 조합하지 못합니다.

구조적 원인은 명시적인 WebIDL type·range 조건과 문맥적 상태 전이 규칙이 여러 계층에 분산되고, multi-process 구현이 각 계층에서 서로 다른 가정을 한다는 데 있습니다. 검증기가 한 상태를 안전하다고 승인했는데 하위 구성요소가 다른 lifetime·thread·buffer 전제를 사용하면, “검증된 의미가 실행까지 보존된다”는 불변조건이 깨집니다.

핵심 공격 원리

LANTERN은 2025년 4월 23일 기준 3,411개 CTS 테스트를 seed corpus로 사용합니다. WebIDL에서 argument type, nullable, range 같은 explicit rule을 가져오고 2025년 8월 5일 WebGPU 규격에서 lifecycle, ordering, alignment 등의 implicit rule을 GPT-5로 제안받아 사람이 검토한 JSON 규칙으로 만듭니다.

Tree-sitter AST를 이용해 object literal과 API 인자를 직접 수정하며 valid 방향과 invalid 방향을 분리합니다. valid 변이는 규칙을 만족하는 범위에서 상태 조합을 늘리고, invalid 변이는 선택한 전제를 의도적으로 어겨 validation과 error path를 압박합니다. 단, 변이된 전체 프로그램의 규격 적합성을 형식적으로 증명하는 것은 아닙니다.

공격 흐름

1. CTS query를 선택하고 로컬 HTTP 서버를 통해 instrumented Chromium에서 실행합니다.
2. 해당 테스트의 API와 객체 관계에 적용 가능한 explicit·implicit 규칙을 찾습니다.
3. scale에 비례해 AST 노드를 선택하고 규칙을 만족하거나 위반하는 값·순서·객체 수명으로 변이합니다.
4. 테스트마다 최대 15초 동안 브라우저를 실행하고 ASan, DCHECK, stderr source location, timeout을 수집합니다.
5. crash를 동일 testcase와 버전에서 반복해 재현하고 최소화·component triage 후 vendor에 보고합니다.

성공 조건 / 실패 조건

탐색 성공에는 WebGPU가 활성화된 Chromium ASan+DCHECK 빌드, CTS seed가 도달시키는 충분히 깊은 상태, 규칙과 AST 위치의 정확한 대응이 필요합니다. 실제 공격 성공에는 crash가 release build에서도 재현되고, 공격자 통제 웹 입력만으로 메모리 corruption이나 보안 경계 위반을 안정적으로 유발해야 합니다.

브라우저 validation이 변이를 조기에 거부하거나, 입력이 단순 규격 오류로 종료되거나, debug-only DCHECK만 발생하면 exploit에는 실패합니다. resource contention으로 browser process가 불안정해지면 신호가 줄거나 비결정적 crash가 섞이며, 실제로 6-process 병렬 실행은 단일 실행보다 관찰 위치가 적었습니다.

연구진의 실험 환경

도구는 약 1,300줄의 Python과 shell로 구현되었습니다. WebGPU를 활성화한 Chromium 146의 ASan+DCHECK 빌드를 주 대상으로 하고, 2025년 2월 4일 공개된 Chromium 133도 비교했습니다. 각 CTS query를 별도 브라우저 실행으로 처리하고 timeout은 15초입니다.

변이 scale은 20, 40, 60, 80, 100이며 valid와 invalid를 각각 단일 실행해 한 구성당 약 15시간을 사용했습니다. 6개 병렬 프로세스 구성도 비교했으며 emulator나 simulation, mainnet이 아니라 로컬 controlled browser 환경입니다.

주요 실험 결과

scale 80에서 valid 변이는 고유 로그 source location 182개, invalid 변이는 195개에 도달했습니다. 전체 위치의 50%에는 1.2

2.1시간, 75%에는 3.6

6.8시간이 걸렸고, 90% 도달은 scale 60 valid 10.9시간, invalid 12.2시간이었습니다. scale 100은 valid 13.0시간, invalid 12.5시간으로 수렴했습니다.

관찰 위치 중 graphics 관련 위치는 대략 14~17개로 적었습니다. Chromium 146 invalid scale 80 ablation에서는 원본 CTS 55개 위치 중 graphics 18개, implicit rule 82/19, explicit rule 187/15, 전체 195/15였습니다. explicit 변이가 전체 로그 위치를 크게 늘렸지만 graphics-specific 위치 증가는 명확하지 않습니다.

6개 병렬 프로세스는 scale 80에서 131개 위치로 단일 프로세스의 195개보다 낮아 resource contention의 영향을 보였습니다. 추가 invalid sweep의 finding 수는 scale 20·40·60·80·100에서 각각 0, 3, 3, 4, 1개였습니다.

실제 발견된 취약점 / 사례

총 7개 crash 신호 중 3개가 재현되었습니다. 첫째, Chromium 133과 146에서 118개가 넘는 frame 경로를 거쳐 Skia font_platform_data DCHECK가 발생했으며 renderer에서 재현되어 보고되었습니다. 둘째, Chromium 146 invalid scale 80에서 V8 ThreadIsolation allocator의 ASan bad free가 ASan과 비-ASan 모두에서 안정적으로 재현되었지만 vendor는 비공개 기존 버그의 duplicate로 처리했습니다. 연구의 기여는 새로운 WebGPU trigger입니다.

셋째, Chromium 133에서 Mojo direct_receiver.cc의 put_result DCHECK가 non-main thread에서 값 5 대 0 불일치로 발생했습니다. Blink 쪽 신호이나 WebGPU와의 필수 인과 및 security impact는 입증되지 않았습니다. 나머지 네 신호는 window_sizer, backend_impl, file_posix, sandbox thread helper 경로에서 나타났으나 재현되지 않았습니다.

저자 주장 vs 실제 증명 범위

규격 기반 변이가 정적 CTS보다 더 다양한 구현 로그 위치와 crash signal을 생성할 수 있다는 주장은 ablation과 실행 결과가 뒷받침합니다. 객체 관계를 보존한 seed와 규칙 기반 변이를 결합하는 설계도 공개된 절차로 설명됩니다.

그러나 일반적인 code coverage 우위, 발견 crash의 exploitability, 모든 신호가 WebGPU 취약점이라는 주장은 증명되지 않았습니다. 특히 V8 bad free는 실제 memory-safety 결함이지만 신규 root cause가 아니며, Skia·Mojo DCHECK는 release 보안 영향이 남아 있습니다.

기존 공격 / 기존 점검 방식과의 차이

일반 coverage-guided fuzzer는 API 문법과 객체 의존성을 무작위로 깨 많은 입력이 얕은 validation에서 종료됩니다. CTS만 실행하면 well-formed 단일 요구사항은 검증하지만 긴 lifecycle·ordering 조합이 제한됩니다.

LANTERN은 CTS가 만든 깊은 상태를 보존한 채 규격 규칙을 변이 operator로 사용합니다. valid와 invalid 방향을 함께 두어 정상 상태 공간의 새로운 조합과 오류 처리 경계를 모두 탐색한다는 점이 다릅니다.

연구의 한계와 주의해서 볼 부분

저자들은 Chromium 중심 평가, 제한된 crash triage, 로그 위치 coverage, implicit rule 생성의 불완전성을 한계로 인정합니다. 네 개 비재현 신호는 환경 잡음일 수 있으며 15초 timeout과 브라우저 재시작이 장기 상태 버그를 놓칠 수 있습니다.

추가로 Chromium 146은 실험 당시 pre-release 계열이므로 운영 안정판의 실제 노출과 다를 수 있습니다. 드라이버·OS·GPU별 차이, sandbox 이후 영향, 사용자 환경의 WebGPU 정책을 측정하지 않았고, 비교 대상 fuzzer의 동일 예산 end-to-end 실험도 더 필요합니다.

공개 PoC / Exploit / Tool / Artifact 분석

논문과 확인 가능한 공식 자료에는 LANTERN 구현이나 최소 crash testcase의 공개 저장소 URL이 제시되지 않았습니다. 따라서 현재 누구나 내려받아 재현할 수 있는 공개 LANTERN PoC가 있다고 표현할 수 없습니다.

gpuweb/cts 공식 저장소는 공개되어 있지만 LANTERN의 입력 seed이자 독립적인 표준 CTS이지 이 논문의 도구·exploit artifact가 아닙니다. W3C WebGPU 규격 역시 규칙의 공식 근거일 뿐 구현 공개를 대신하지 않습니다. vendor disclosure 세부와 비공개 duplicate는 접근 가능한 범위가 제한됩니다.

레드팀 / 모의해킹에서 어떻게 활용할까

브라우저 보안팀은 production 사용자가 아니라 격리된 ASan·UBSan·DCHECK 빌드와 테스트 GPU에서 규격 기반 변이를 사용해야 합니다. 관찰 포인트는 renderer·GPU process 분리 crash, sanitizer stack, validation message, IPC disconnect, driver reset, 동일 seed의 반복 재현률입니다.

검증 기준은 debug assertion 한 번이 아니라 동일 입력의 안정 재현, release 또는 sanitizer build 영향, 공격자 통제 데이터에서 fault까지의 data flow입니다. GPU reset, 시스템 UI 불안정, host 메모리 증가, 반복 비재현이 나타나면 batch를 중단하고 seed·환경·로그를 보존합니다.

실제 점검 시 추가할 체크리스트

• 브라우저·Dawn·GPU driver·OS 버전과 WebGPU feature flag를 고정합니다.
• CTS commit과 W3C 규격 snapshot을 기록해 규칙의 기준 시점을 보존합니다.
• 명시 규칙과 lifecycle·ordering·alignment 규칙을 별도 operator로 관리합니다.
• valid/invalid 의도를 실제 전체 프로그램 적합성과 혼동하지 않고 validation 결과를 기록합니다.
• renderer, browser, GPU process, driver 로그와 sanitizer stack을 correlation합니다.
• crash는 최소 3회 반복하고 debug-only assertion과 release memory-safety를 구분합니다.
• 고유 source location 외에 edge·function coverage와 graphics-specific coverage를 함께 수집합니다.
• 병렬도 증가 시 처리량뿐 아니라 coverage 감소와 자원 고갈을 측정합니다.
• 최소 testcase와 vendor triage 상태, duplicate 여부, 패치 버전을 추적합니다.

실무 가치 평가

복잡한 stateful API를 점검할 때 규격을 mutation grammar로 사용하는 설계는 가치가 높습니다. WebGPU뿐 아니라 WebUSB, WebCodecs, 그래픽·미디어 IPC처럼 CTS는 풍부하지만 상태 조합이 큰 영역에도 적용할 수 있습니다.

현재 결과는 강한 탐색 아이디어와 유의미한 memory-safety trigger를 보여 주지만 완성된 공개 도구나 다중 구현 검증은 없습니다. 브라우저 공급자 내부 fuzzing 보강에는 유망하나, 외부 레드팀이 바로 재현 가능한 exploit package로 보기는 어렵습니다.

결론

LANTERN은 규격 준수 테스트와 일반 fuzzing 사이의 간극을 CTS 기반 상태 보존 변이로 메웁니다. 핵심 교훈은 WebGPU 보안이 개별 인자 검증만이 아니라 긴 객체 수명과 계층 간 의미 보존에 달려 있다는 점입니다.

7개 신호 중 3개만 재현되었고 최종 보안 영향은 제한적으로 입증됐으므로 결과를 과장해서는 안 됩니다. 그럼에도 기존 V8 memory-safety 결함으로 이어지는 새 WebGPU trigger와 정량 ablation은 규격 기반 fuzzing의 실무적 가능성을 보여 줍니다.