#sandbox

4편은 ".at() 무가드 OOB read는 확정, 그런데 write는 여전히 막혀 있고 read→write 다리는 addrof/fakeobj뿐"으로 끝났다. 5편은 그 다리를 건너 라이브 flag까지 가는 기록이다 — 그리고 솔직히 3일이 걸렸다. addrof/fakeobj 부트스트랩이 "nursery monoculture로 불가능"이라던 결론을 뒤집고(진짜 원인은 globalThis 저장이 fold를 deopt시킨 것), fake FixedDoubleArray로 첫 forward 케이지 R/W를 열고, 그게 GC 신뢰성에서 이틀을 막았다가 "오프셋 가정을 런타임 leak으로 바꾸는" 한 줄로 5/5가 됐다. 거기서 fake Float64Array의 base_pointer를 갈아끼워 data_ptr을 절대주소로 지정하는 양방향 R/W로 backward 인스턴스까지 읽고, V12 Revenge에서 쓴 imported_function_targets 덮기로 절대주소 누출 없이 execve("/bin/sh")까지. 익스는 서버 한도(2000B)에 맞춰 1999바이트로 깎았고, 로컬 10/10이 서버에선 0/12로 죽길래 진단을 보냈더니 mapArr 하나만 환경마다 달랐다(0x18d7b9 vs 0x10d7b9) — 그걸 런타임 leak으로 적응시켜 host3.dreamhack.games에서 flag를 회수했다.

"V8이 너무 느리다, V12로 갈아타자 (* 내부 함수 없이 *)" — array-shift Torque 빌트인에서 빈 배열 가드 한 줄을 주석 처리한 게 전부인 버그다. 길이 0 배열에 .shift()를 부르면 newLength = 0-1 = -1, 그게 그대로 length 필드로 들어가 length(0xFFFFFFFF) ≫ capacity 인 OOB 배열이 만들어진다. 이 글은 그 OOB에서 케이지 임의 R/W·addrof를 세우고 — 한 번은 "V8 샌드박스가 절대주소 누출을 막아 코드 실행이 불가능하다"고 잘못 결론 내렸다가 — 출제자가 의도한 정석 기법을 찾아 뒤집은 기록이다. 핵심은 WasmInstanceObject의 imported_function_targets: 임포트 함수의 호출 타깃을 담은 "케이지 안 ByteArray"가 실은 raw(샌드박스 밖) 포인터라, 케이지 쓰기만으로 import 호출을 임의 주소로 보낼 수 있다. 거기에 jump_table_start로 RWX를 직접 읽고, 셸코드 실행 순간 살아있는 r14(케이지 베이스)로 wasm 메모리를 가리켜 execve("flag_reader") — 절대주소 누출 없이 샌드박스를 빠져나와 라이브 flag까지 회수했다.