[💎 Diamond 1] Math.exp가 NaN을 잊을 때 (5) — read에서 flag까지: 불가능이라던 부트스트랩을 뒤집고 라이브 서버를 뚫다 — DreamHack EXP-NaN

문제는 그 짝(store)이 전멸이라는 것. bracket store a[i]=v는 trap, TypedArray·fill·with는 노옵/클램프/RangeError, a.length 키우는 건 elements를 같이 키워 치유. 4편의 결론은 "write로 가는 유일한 길은 read 프리미티브로 객체 그래프를 위조하는 것" — addrof/fakeobj.

addrof/fakeobj는 브라우저 익스의 정석이다(saelo). 하지만 이 문제는 read만 주고, reader의 타입이 반환을 가른다(4편). double reader는 인접 객체 포인터를 "수"로, object reader는 인접 double 비트를 "객체"로 본다. 4편은 그걸 이렇게 정리하고 끝냈다 — "double reader 옆엔 핫루프가 뿌린 [1.1..] 사본의 바다뿐이라, victim 객체배열이 도달 오프셋에 한 번도 안 온다. monoculture라 부트스트랩이 안 된다."

그 문장이 사흘짜리 함정이었다.

2. 💡 "불가능"의 진짜 원인 — fold를 깬 건 monoculture가 아니라 globalThis였다

4편을 쓰고 나서도 부트스트랩을 계속 두드렸다. addrof 가젯은 이렇게 생겼다.

처음엔 o를 globalThis.O = [...]에 저장했었다. 핫루프 도중 victim 배열이 GC에 쓸려나가지 않게 살려두려는 의도였다. 그런데 그때마다 OOB가 victim 대신 [1.1..] 더블만 읽었다 — 그래서 4편에서 "monoculture"라고 적었다.

원인은 어이없었다. globalThis에 저장하는 store가 TurboFan에서 별도의 부작용으로 잡혀 reshape된 인덱스 식의 fold를 deopt시키고 있었다. OOB가 안 자란 게 아니라, 그 store 때문에 최적화가 풀려 .at이 정상 경로로 돌아간 거였다. 살려두는 방법을 함수 파라미터 sink의 원소로 바꾸자(sink[0]=o, StoreElement) victim이 살아남으면서도 fold가 유지됐고, OOB가 o의 영역까지 정확히 도달했다.

fakeobj는 거울상이다. object reader oR = [ro,ro,ro,ro] 옆에 d = [dv, …×24](dv = 위조할 주소를 비트로 인코딩한 double)를 두고, oR.at(idx)가 d의 double을 "객체"로 반환하게 한다. 여기엔 잔기술이 둘 더 필요했다 — fresh addrof(fakeobj 직전 주소를 다시 계산, GC staleness 회피)와 런타임 캘리브레이션(oR.at이 d의 어느 슬롯을 읽는지가 힙 상태에 따라 드리프트 → fakeobj(addrof(CAL))===CAL이 성립하는 idx 배수 m을 런타임에 찾음).

돌려보면 부트스트랩이 결정적으로 선다. addrof는 객체마다 다른 주소를 뱉고, 캘리브레이션은 매번 같은 m(=10)을 찾는다.

sink[0]=o 한 줄과 fresh addrof, 이 둘로 네 편을 내리 "닫혔다"고 믿게 했던 벽이 사실 디버그 코드 한 줄(globalThis 저장)이었다. 이런 문제의 잔인한 점이다.

한 번 적어둔다. 이 부트스트랩을 "불가능"이라고 네 번 결론 냈었다. 매번 근거가 그럴듯했다(monoculture, 타입-매칭 인접, 자연 티어업의 비결정성…). 근거가 그럴듯할수록 더 의심해야 한다는 걸 이 문제가 가르쳤다.

3. 🧱 첫 케이지 R/W — fake FixedDoubleArray, 그리고 오프셋이라는 늪

addrof + fakeobj가 있으면 그 다음은 교과서다. 가짜 배열을 위조해 임의 주소를 읽고 쓴다. V8은 포인터 압축 샌드박스(4편의 도식)라, 모든 객체 포인터가 4GB 케이지 안의 32비트 오프셋이다. 그래서 "케이지 R/W"가 1차 목표다.

cont(young double 배열)에 가짜 JSArray 헤더를 깐다. cont[0]=[map|props], cont[1]=[elements→fda|length=huge]. fakeobj(cont의 elements_data)로 가짜 PACKED_DOUBLE 배열 fa를 만들고, fa.elements가 또 다른 가짜 FixedDoubleArray(fda[0]=[FDAmap|huge])를 가리키게 한다. 그러면 fa[i]=*(fda_data+i·8)로 forward 임의 R/W가 열린다.

여기서 이틀을 까먹은 함정 두 개. 둘 다 GC가 객체를 옮긴다는 데서 온다.

잠깐 — V8의 세대별 GC를 알아야 이 늪이 보인다

이건 이 문제 풀이의 핵심 배경이라 외부 도식으로 짚는다. V8(Orinoco)은 세대별 GC다. 새로 만든 객체는 Young Generation(Nursery)에 들어가고, scavenge를 몇 번 살아남으면 Old Generation으로 승격(promote)된다.

게다가 young scavenge는 mark-compact가 아니라 evacuation이다 — From-Space의 살아있는 객체를 To-Space로 복사하면서 주소가 통째로 바뀐다. 즉 내가 위조에 쓰는 young 배열은, scavenge가 한 번만 돌아도 다른 주소로 이사한다.

이게 왜 함정이냐면:

• 오프셋. young 객체는 elements가 JSArray 바로 앞 −16에 인접해 있다. 그런데 old-gen으로 승격되면(또는 evacuation으로 이사하면) elements와 JSArray가 따로 배치돼 비인접이 된다. -16을 가정하고 fakeobj하면 가짜 객체의 map 자리에 1.1(0x9999999a)이 와서 Array.isArray가 그걸 map으로 역참조하다 SEGV. gdb로 보니 old-space cont의 elements는 무려 +432에 있었다. "young만 인접" 이 핵심.
• GC 타이밍. 더 미묘한 건, 같은 코드를 인라인으로 두면 깨지고 buildRW() 함수로 감싸면 3/3 안정이었다는 것. 함수 호출 경계가 cont/fda를 그 호출 안에서 fresh young으로 할당·소비하게 만들어, 주변 코드의 할당이 끼어들 틈을 줄인 것으로 보인다. 이유를 완전히 규명하진 못했지만 재현은 확실했다 — 인라인 0/N, 함수 래핑 3/3.

정렬도 한 겹 더 있었다. object/double 로드 모두 *(elements + idx·4 + 7) 형태라, 4-mod-8 주소는 fa[i](8바이트 스텝)의 상위/하위 32비트로 갈라 읽어야 했다. rd32(addrof(x))가 x.map을 정확히 뱉을 때(10/10), wr32로 da[0]을 덮어 바뀔 때(3/3) — forward 케이지 R/W가 섰다.

4. 🔁 사흘째의 반전 — 가정을 leak으로 바꾸다

forward R/W가 섰는데도 풀체인이 안 됐다. 탈출 타깃인 WASM 인스턴스가 R/W base보다 거의 항상 **뒤(backward)**에 떨어졌기 때문이다(인스턴스가 먼저 할당된다). fake-FDA는 fa[i], i ≥ 0이라 앞쪽만 읽는다. 뒤를 읽으려고 fake Float64Array(다음 절)로 확장했더니, 이번엔 그 부트스트랩이 GC에서 무너졌다 — cont+fda+rta+tacont 네 배열의 누적 할당이 scavenge를 유발해 young cont를 옮겨버려(바로 위 evacuation) fa.map=1.1 크래시. cageta2.js, cageta3.js 전부 0/N.

이게 이 문제에서 가장 길게 막힌 지점이다. 이틀을 같은 SEGV(…999999a1)만 봤다. "GC 신뢰성은 V8 익스의 본질적 난제고, primitive 재설계가 필요할지도"라고 메모에 적어두고 거의 접으려던 참이었다.

반전은 한 가지를 의심하면서 왔다 — 나는 왜 tacont의 elements가 −64에 있다고 가정하고 있나? (8원소 double 배열이니 −(8·8)일 거라고.) 그 가정을 버리고, 이미 작동하는 fake-FDA(forward)로 tacont의 실제 elements 포인터를 읽었다.

실측하니 tE(leak) = 0x104d38, −64 가정 = 0x104cd8 — 정확히 0x60 어긋나 있었다. tacont는 부트스트랩에서 할당이 더 많아 승격/이동이 잦았고, 그래서 가정이 깨졌던 것. cont(−16)는 타이트 윈도우라 가정을 유지할 수 있었지만, tacont는 leak이 필수였다. 이 한 줄로 cageta4.js가 5/5가 됐다. V8 익스의 신뢰성은 "구조적 오프셋 가정"이 아니라 "런타임 leak"에서 온다 — 사흘 만에 몸으로 배운 한 문장이다.

5. ↔️ 양방향 임의 R/W — fake Float64Array의 base_pointer를 갈아끼우다

이제 backward까지 읽어야 한다. FixedDoubleArray는 data가 헤더 뒤에 인라인이라 위치를 못 옮긴다. 하지만 Float64Array(TypedArray)는 data_ptr을 필드로 들고 있다. 이걸 위조하면 절대 오프셋을 직접 지정할 수 있다. 먼저 진짜 TA의 필드를 natives %DebugPrint로 부검했다.

여기서 공식이 나온다. on-heap TA는 data_ptr = decompress(base_pointer) + 7(external_pointer가 cage+7로 상수). 샌드박스 11.2의 TA는 byte_length·external_pointer가 인코딩된 sandboxed 필드라 손으로 위조하기 까다롭다. 그래서 이해하려 들지 않고 진짜 Float64Array의 필드 전체(+0x00~+0x3c)를 fake-FDA로 leak해 tacont에 통째 복사했다. 그리고 base_pointer(+0x34) 하나만 매 접근마다 Y − 7로 갈아끼웠다.

data_ptr = cage + (Y−7) + 7 = cage + Y. 그래서 ft[0] = *(Y) — 방향도 정렬도 무관. backward 인스턴스도 한 발에 읽힌다. 단, base_pointer는 태그드 포인터라 wild 상태에서 GC가 돌면 그 가짜 포인터를 추적하다 OOM이 난다. 읽은 직후 원복하고, wild 윈도우 안에서는 할당을 0으로(공유 버퍼) 만들어 GC 자체가 안 끼게 했다.

프리미티브를 한 번에 검증하면 이렇다 — addrof·fakeobj·fake-FDA(forward)·fake-TA(양방향)가 한 실행에서 전부 선다.

da는 R/W base보다 backward에 있는데도 read64(da)가 da.map(0x18d7b9)을 정확히 뱉고, write64로 da[0]이 13.371337로 바뀐다. 5/5 결정적.

6. 🚀 샌드박스 탈출 — 절대주소 누출 없이 RIP을 잡다

케이지 R/W가 섰지만, 샌드박스는 케이지 밖 raw 포인터 읽기를 막는다. 셸코드를 어디에 두고 어떻게 점프하나. 이건 V12 Revenge에서 확립한 기법을 그대로 가져왔다 — 같은 V8 11.2라 오프셋이 동일하다. 먼저 import를 가진 최소 wasm 인스턴스를 부검한다.

핵심은 이 두 필드가 케이지 안에 평문으로 있다는 것.

• +0x60 jump_table_start — 샌드박스 밖 RWX의 절대주소. read64(inst+0x60)로 그냥 읽힌다.
• +0x18 imported_function_targets — import 콜 타깃을 담은 ByteArray. data[0]이 import0이 실제로 점프하는 곳.

ByteArray+8(콜 타깃)을 jt + 0x81d로 덮으면, inst.exports.g()(=call import0)가 그 RWX 주소로 점프한다. 절대주소를 누출할 필요가 없다 — jt는 인스턴스 안(+0x60)에 있고, 덮는 건 케이지 R/W로 충분하니까.

jt + 0x800엔 s 함수의 Liftoff 코드가 있고, 그 안 +0x81d가 셸코드 진입이다. 셸코드는 i64.const 청크로 심는다 — i64.const 0x...는 movabs rax, imm64로 컴파일되고, 그 8바이트 피연산자가 곧 코드다. 각 청크 [6B 코드][eb 02]로 다음 movabs 프리픽스(48 b8)를 건너뛰며 이어진다.

path는 JS에서 wasm 메모리[0]에 써둔다. 처음엔 flag_reader 경로를 직접 넣으려 했는데 — 서버의 진짜 flag_reader는 파일명에 md5가 붙어 있고(배포 시 mv flag_reader flag_reader-$(md5sum)), 그 md5를 모른다. 그래서 path = "/bin/sh"로 두고 더 영리하게 풀었다. execve("/bin/sh") 뒤엔 d8의 stdin이 곧 네트워크 소켓이다. runner가 <EOF>까지 읽고 d8을 띄우면, 그 뒤로 내가 보내는 바이트가 그대로 셸의 stdin이 된다. 그러니 <EOF> 뒤에 ./flag_reader-*를 글롭으로 주입하면 모르는 md5도 셸이 알아서 매칭한다. 한 연결로 끝.

7. ✂️ 2000바이트 — 익스를 다이어트하다

서버 runner는 친절하게 알려준다. Please send your own payload! … Max: 2000bytes. 완성된 익스는 처음 2500바이트였다. 깎아야 했다.

• fakeobj idx를 하드코딩(캘리브레이션에서 m=10이 8/8 일관) → 검색 루프 제거
• addrof 가젯과 mapArr-leak 가젯을 한 팩토리 mk(O)로 병합(둘 다 o=[v,v,v,v], OFF만 다름)
• WASM을 hex + Uint8Array.from(...match(/../g), h=>+("0x"+h))로(466자→274자), 셸코드는 6바이트 청크로 패킹(8→7)
• 공유 ArrayBuffer 헬퍼, Math.floor(k/8)→k/8|0, 화살표 함수…

이렇게 1999바이트까지 깎았다. wasm 모듈은 137바이트.

본문 곳곳에 쪼개 보인 조각들을 합치면, 서버에 그대로 보내는 1999바이트 페이로드가 된다. 위에서 설명한 단계가 한 줄씩 어디에 들어가는지 주석으로 표시했다.

로컬 검증은 결정적이었다. printf 'echo OK\n' | ./out/d8 exploit.js를 12번 돌려 셸 도달률을 센다.

풀체인은 서버 harness(runner.py)를 그대로 로컬에서 돌려 확인했다 — 익스를 보내고 <EOF> 뒤로 셸 명령을 주입한다.

uid가 찍히고, ls flag*로 파일이 보이고, 글롭으로 flag_reader가 실행돼 (로컬 미러의 가짜) flag가 나온다. 여기까지 오는 데 사흘. 로컬 10/10. 이제 서버만 남았다고 생각했다. 그게 아니었다.

8. 🌐 로컬은 10/10인데 서버는 0/12 — mapArr 하나가 달랐다

host3.dreamhack.games:23039에 쏘니 전부 SEGV였다. 로컬에서 10/10인 익스가 서버에서 0/12. 같은 d8 바이너리인데. 크래시 주소는 익숙한 …999999b5(fa.map = 1.1) — 가짜 FDA가 깨진 모양.

여기서 한탄을 한 번 했다. 사흘 걸려 결정적으로 만든 익스가, 서버에선 한 발도 안 맞는다.

추측으로 패치하지 않고 진단을 보냈다. d8의 print는 stdout(소켓)으로 나오니, 익스 대신 "값을 출력하는 진단 페이로드"를 보내 서버의 실제 상수를 읽었다 — addrof OFF(victim-의존성 자가검출)와 가짜 객체에 필요한 상수들(o=double 배열의 map을 OFF 스캔으로 leak).

mapArr 하나만 달랐다. props(빈 FixedArray), FDAmap(FixedDoubleArray map), fakeobj_m, addrof OFF는 전부 동일. 이유가 있다 — props·FDAmap은 read-only 루트라 스냅샷에 박혀 결정적이지만, PACKED_DOUBLE JSArray map은 per-Isolate map-space에 만들어져 힙 레이아웃에 따라 시프트한다. 로컬과 서버는 부팅 시 할당 이력이 미세하게 달라(타이밍·티어업) map-space 베이스가 0x80000만큼 어긋나 있었다.

고치는 건 이제 명확했다 — mapArr을 런타임에 leak한다. o를 double 배열로 두고 OFF를 스캔해, hi32 == props(0x1c9)인 슬롯(=그 배열의 map)을 찾아 mapArr을 가져온다.

하드코딩 대신 이 leak을 넣어(약 +200바이트, 다시 깎아 1999 유지) 환경에 적응시켰다.

이게 4편에서 "결정적·재현 가능"이라고 자랑했던 OOB 인덱스의 이면이다. 인덱스 자체는 결정적이지만, 그게 가리키는 힙 주소는 환경마다 다르다. 로컬 박스 하나로 "결정적"을 확인하면, 그 결정성이 환경 독립이라고 착각하기 쉽다. 다이아 1짜리 마지막 함정이 정확히 거기였다.

9. 🏁 flag

mapArr leak을 넣은 1999바이트 익스를 다시 쐈다. pwntools로 익스를 보내고, d8이 execve("/bin/sh")까지 가도록 잠깐 기다린 뒤, <EOF> 뒤로 글롭 명령을 주입한다.

서버 셸이 살아났다. uid=1000(pwn) — d8은 pwn 그룹으로 돈다. 디렉토리엔 flag-3cc99f1c0d9e8255877c19addd1d7ec1(r-------- pwned)와 flag_reader-856b1262a69e0871d532cb9371bed035(r-sr-x--- pwned:pwn, setuid pwned)가 있다.

여기서 한 번 더 막혔다 — ./flag_reader-*를 실행했는데 아무것도 안 나왔다. ELF를 까보니(setreuid/system//bin/bash 심볼) flag_reader는 flag를 직접 출력하는 게 아니라 setreuid(pwned) 후 셸을 띄우는 래퍼였다. 즉 그걸 실행하면 pwned 권한의 셸이 stdin을 기다리며 멈춘다. 그래서 flag_reader를 글롭으로 실행해 pwned 셸을 얻은 뒤, 그 셸에 cat flag-*를 한 번 더 먹여야 한다 — flag는 400/pwned 소유라 pwn은 못 읽지만, flag_reader가 띄운 pwned 셸은 읽는다.

(라이브 서버는 윈도우마다 셸 도달률이 7/7 ↔ 0/7로 빠르게 출렁인다 — 인스턴스의 GC 상태가 시시각각 다르기 때문. 좋은 윈도우가 열릴 때 연결하면 맞는다. 같은 풀체인을 서버 harness(runner.py)로 로컬에서 재현한 게 7절의 05b다.)

서버에선 확률적이다(mapArr leak + GC 변동, 그리고 인스턴스의 GC 상태가 시간대마다 다름) — 좋은 윈도우에서 연결을 재시도하면 맞는다. 사흘 만에, 4번 "막혔다"고 적었던 그 부트스트랩을 지나, 라이브 서버에서 flag가 나왔다.

🗺️ 전체 시리즈 한눈에 — 사흘의 지도

이 문제는 "막힌 줄 알았다가 뒤집는" 게 다섯 편 내내 반복됐다. 시리즈를 한 장으로 묶으면 이렇다.

사흘의 타임라인으로 보면:

• 1일차 — 버그를 트리거하고 "OOB가 왜 안 자라는가"를 끝까지 추적했다(1편). 결론: 11.2 하드닝이 값-range 경로를 정조준해 막았다.
• 2일차 — 그 하드닝을 소스로 부검하고(2편), 남은 출구를 전수로 두드리고(3편), 막힌 줄 알았던 표면에서 .at() 한 reducer가 안 막힌 걸 찾았다(4편). read 프리미티브 확보.
• 3일차 — 이 하루에만 "막혔다"를 네 번 적었다. 부트스트랩 반전 → fake-FDA → fake-TA → 탈출 → flag(5편).

다이아 1짜리 난이도의 정체가 여기 있다 — 한 번의 천재적 통찰이 아니라, "닫혔다"는 그럴듯한 결론을 다섯 번 의심하고 다섯 번 뒤집는 끈기였다. 1편의 "OOB가 안 자란다", 3편의 "다 닫혔다", 4편의 "monoculture로 불가능", 5편의 "GC로 불가능"·"서버에서 안 맞는다" — 전부 근거가 단단한 오판이었고, 전부 한 줄·한 가정을 의심하면서 풀렸다.

🛡️ 방어 관점 — 결정성과 환경 독립은 다르다

이 시리즈를 관통한 방어 교훈은 "하드닝은 공용 헬퍼에 박아야 한다"(4편)였다. 5편이 거기에 하나를 더한다 — 공격자의 안정성도, 방어자의 가정도, "내 박스에서 결정적"에 속는다.

• 공격 쪽: 부트스트랩을 "monoculture로 불가능"이라 네 번 결론 냈지만 진짜 원인은 디버그 코드 한 줄(globalThis 저장)이었고, fake-TA가 "GC로 불가능"해 보였지만 진짜 문제는 오프셋 가정 한 곳이었다. 그럴듯한 불가능일수록 의심하라.
• 환경 쪽: 로컬 10/10이 서버 0/12였던 건 익스 버그가 아니라 mapArr이 per-Isolate라 환경마다 다른 것. 결정적 OOB 인덱스도 가리키는 주소는 환경 의존이다. 신뢰성은 하드코딩이 아니라 런타임 leak에서 온다.

방어 관점에선 — 이 익스가 환경 상수 하나(per-Isolate map)에 그렇게 민감했다는 건, 역으로 map-space 레이아웃 랜덤화(스냅샷 시드/슬라이드)가 익스 신뢰성을 크게 떨어뜨린다는 뜻이다. 실제로 V8 샌드박스는 이후 케이지 내부 배치를 덜 예측 가능하게 만드는 방향으로 움직였다. "결정적이지만 환경 의존"이라는 표면을 "비결정적"으로 밀어내는 게, 이 계열 익스를 가장 싸게 죽이는 길이다.

면책: 인가된 DreamHack CTF(Div1 출제작) 풀이 기록이다. 익스는 패치된 d8 프로세스 안에서만 동작하고, 라이브 검증은 본인에게 발급된 챌린지 인스턴스에 한정한다. V8 11.2.214.14 전용 — 최신 V8엔 적용 안 된다. 셸코드/페이로드는 교육·방어 목적의 분석을 위한 것이다.

📚 참고

• V8 소스 commit 6538a20a (11.2.214.14) — compiler/js-call-reducer.cc(.at reducer), wasm/wasm-objects.h(imported_function_targets / jump_table_start 오프셋)
• saelo, Exploiting Logic Bugs in JavaScript JIT Engines — addrof/fakeobj 정석
• V8 blog, Trash talk: the Orinoco garbage collector — 세대별 GC / scavenge evacuation(본문 GC 도식 출처) · Pointer Compression · The V8 Sandbox
• 본인 글, DreamHack V12 Revenge — imported_function_targets 덮기로 절대주소 누출 없이 RIP 제어(이 글이 그대로 재사용)
• 이미지 출처: 세대별 GC·V8 파이프라인·샌드박스·IEEE-754 도식 = v8.dev / 공개 자료. 나머지 도식·터미널 스샷은 직접 제작·캡쳐.
• 이 시리즈: 1편 — 버그·트리거 · 2편 — 소스 부검 · 3편 — 전수 점검 · 4편 — .at()이 열려 있었다