[💎 Diamond 1] Math.exp가 NaN을 잊을 때 (3) — 남은 출구를 전부 두드리다: 의도된 sink마저 막혀 있었다 — DreamHack EXP-NaN

문제: DreamHack — EXP-NaN (Dreamhack CTF Season 4 Round #5, 🚩Div1 출제작) 분류: Pwnable (Browser / V8 JIT) 난이도: 💎 Diamond 1 이 글: 시리즈 3편 — 남은 출구 전수 점검. (1편: 버그·트리거 · 2편: 소스 부검)

2편은 한 가지를 소스로 확정하고 끝났다 — 타입혼동으로 CheckBounds를 지워 OOB를 내는 표준 경로(abiondo·doar-e·Quick-Maffs)는 11.2에서 통째로 닫혔다. CheckBounds는 이 빌드에서 절대 사라지지 않고, 인덱스가 in-bounds로 증명되면 검사가 제거가 아니라 kAbortOnOutOfBounds 트랩으로 바뀐다. 그래서 "첫 OOB를 여는 비표준 한 수"가 있어야 한다고 적고 마쳤다.

이 3편은 그 비표준 한 수를 찾으러, CheckBounds를 거치지 않는 출구를 가능한 한 전부 두드린 기록이다. 결론부터 말하면 — 첫 OOB는 못 열었다. 하지만 그 과정에서 이 문제의 구조가 한 겹 더 드러났다: 이 버그류의 의도된 해법으로 보이는 길마저, 패치의 사정거리 밖이라 막혀 있다.

소스는 챌린지 patches/README.md가 지정한 빌드 — V8 commit 6538a20a (11.2.214.14). 줄 번호는 그 commit 기준.

🧭 이 글의 위치

1·2편을 안 봤어도 따라올 수 있게 한 줄 요약: Math.exp의 반환 타입에서 NaN을 빼는 패치 한 줄 때문에, TurboFan은 Math.exp(x)가 절대 NaN이 아니라고 믿는다. 하지만 Math.exp(NaN)=NaN이다. 이 어긋남은 진짜로 살아 있다. 문제는 그걸 메모리 침범으로 바꾸는 sink가 11.2에선 다 막혀 있다는 것.

• 1편: 버그·트리거, NaN이 인덱스로 가는 길마다 정화되는 삽질, 그리고 무조건 트랩 하드닝.
• 2편: 그 트랩이 왜 트랩인지 소스 부검. CheckBounds 제거가 죽은 경로, doar-e 우회를 정조준해 막은 두 번째 검사.
• 3편(여기): CheckBounds를 안 거치는 출구를 전수로 두드림 → 그래도 안 열림 → 의도된 sink도 막혀 있다는 발견 → 다음 한 수.

🧭 30초 용어 정리 (3편부터 봐도 따라오게)

3편은 출구 사냥이라 용어가 몇 개 더 필요하다.

• typer: TurboFan(V8 최적화 컴파일러)의 타입 추론기. 각 값의 가능한 범위/종류를 컴파일 타임에 좁혀, "이 값은 항상 0~3"이라 증명되면 검사를 지운다. 이 버그는 typer가 Math.exp를 "NaN 아님"으로 잘못 좁히는 것.
• CheckBounds / kAbortOnOutOfBounds: 배열 경계검사 노드. 11.2에선 인덱스가 in-bounds로 증명되면 이 검사를 제거하는 게 아니라 **트랩(abort)**으로 바꾼다(2편). 그래서 typer를 속여 OOB를 내려 하면 silent OOB가 아니라 SIGTRAP이 난다.
• cvttsd2si: x86의 double → int32 변환(truncation) 명령. 입력이 NaN/범위초과면 0x80000000(INT_MIN)을 뱉는다. typer가 "NaN 아님"을 믿으면 보정 없이 이 명령만 깔리고, 런타임 NaN이 그대로 INT_MIN으로 샌다. 발산의 물리적 근원.
• sink: 발산한 값(또는 no-NaN 믿음)을 받아 실제 메모리 침범으로 바꿔주는 연산. 인덱스(a[i]), 길이(new Array(n)), 빌트인 내부 오프셋 등. 3편의 주제 = "어떤 sink가 열려 있나".
• length-construction: 이 버그류의 교과서 의도 해법. 발산값을 new Array(v)에 넣어 typer는 "작은 배열"로 믿고 백킹을 작게 잡는데 런타임 길이는 거대해, length > capacity 불일치가 나면 그 배열로 백킹 밖을 읽고 쓴다.

📋 문제 개요

V8은 JS를 Ignition 바이트코드로 돌리다, 핫해지면 TurboFan으로 최적화한다. 버그도 익스도 전부 그 최적화 단계 안에서 일어난다.

출처: v8.dev (Google V8 공식 블로그)

🩹 패치 — 정확히 뭐가 바뀌었나

patches/v8.patch는 두 가지를 한다. 첫째, 버그 본체 — typer.cc의 JSCallTyper에서 Math.exp를 Math.abs 무리에서 떼어내 NaN을 뺀 타입을 준다.

   // Unary math functions.
   case Builtin::kMathAbs:
-  case Builtin::kMathExp:
     return Type::Union(Type::PlainNumber(), Type::NaN(), t->zone());
+  case Builtin::kMathExp:
+    return Type::PlainNumber();

Math.abs는 여전히 Union(PlainNumber, NaN) — NaN을 포함한다. Math.exp만 PlainNumber()로, NaN이 빠졌다. 딱 이 한 줄이 typer에게 "Math.exp는 절대 NaN을 안 돌려준다"는 거짓말을 심는다.

둘째, d8 락다운 — d8.cc/d8-posix.cc에서 파일·OS 접근을 전부 주석 처리한다.

-  global_template->Set(isolate, "read",  ReadFile);
-  global_template->Set(isolate, "load",  ExecuteFile);
-  global_template->Set(isolate, "Realm", CreateRealmTemplate);
+  // global_template->Set(isolate, "read",  ReadFile);   // 막힘
+  // global_template->Set(isolate, "load",  ExecuteFile);// 막힘
+  // global_template->Set(isolate, "Realm", ...);        // 막힘
// os.system, d8.file.read/execute, readbuffer/readline/writeFile … 전부 주석

이게 문제의 성격을 정한다. read·load·os.system·Realm·d8.file이 다 사라졌으니, flag를 파일로 읽거나 명령으로 빼낼 길이 없다. 남은 건 메모리 손상으로 코드 실행을 잡아 execve("./flag_reader-…")를 직접 부르는 것뿐 — 즉 이 챌린지는 순수 메모리 손상 RCE만 의도한다. read 프리미티브 하나로는 절대 안 끝나는 이유다.

🗺️ 방법 — 남은 출구를 어떻게 골랐나

2편의 결론이 길을 좁혀준다. 모든 인덱스/길이 검사가 CheckBounds로 수렴하고, 그게 deopt 아니면 abort라면 — 답은 반드시 CheckBounds를 거치지 않는 메모리 sink다. 그래서 후보를 이렇게 잡았다.

"no-NaN(PlainNumber) 믿음이 깨뜨릴 수 있고, 그 결과가 CheckBounds가 아닌 다른 곳(할당 크기, 빌트인 내부 인덱스, 표현형 선택, byteOffset)으로 흘러 메모리에 닿는 연산은 무엇인가?"

이 기준으로 후보 sink를 카테고리별로 전부 나열하고, 추측으로 끝내지 않고 각각을 패치된 d8에 직접 때려봤다. 판정 기준은 단순하다 — exit code 133(SIGTRAP)=트랩, undefined/범위 안 값=정화, 인접 메모리의 map/포인터 비트가 새어 나오면=진짜 OOB.

🧮 먼저, 어긋남이 살아 있다는 증거

출구를 두드리기 전에, 받아줄 "발산한 값"이 실제로 존재하는지부터 못 박았다. cvttsd2si(보정 없는 float→int 변환)는 NaN을 만나면 자바스크립트의 ToInt32(NaN)=0이 아니라 0x80000000(INT_MIN) 을 돌려준다(1편). 이걸 Quick-Maffs식 산술 체인에 태우면, typer는 결과를 작은 상수로 "증명"하는데 런타임은 INT_MIN으로 갈라진다.

function foo(x) {
  let v = Math.exp(x);   // 패치 typer: PlainNumber (NaN 아님) — JSCall 유지(speculation off)
  v = Math.sign(v);      // typer Range(-1,1)  ; 런타임 sign(NaN)=NaN
  v = Math.abs(v);       // typer Range(0,1)
  v += 2;
  v >>= 1;               // typer Range(1,1)
  v += 10;               // typer Range(11,11) — "결과는 무조건 11"
  return v;
}

>>= 같은 비트연산이 들어가 typer는 결과를 Range(11,11)(상수 11)로 굳게 믿는다. 그런데 런타임 Math.exp(NaN)=NaN이 보정 없이 INT_MIN으로 떨어지고, 그게 체인을 타고 내려가 전혀 다른 값이 된다. 최적화된 버전(OPT)과 절대 최적화 안 한 참조(REF)를 나란히 찍어보면:

../extracted/deploy/out/d8 --allow-natives-syntax qm_chain2.js

REF는 정직하게 10(ToInt32(NaN)=0 → 산술), OPT는 -1073741813. 컴파일러가 "11"이라 증명한 변수가 런타임엔 음수 거대값이다. soundness가 깨진 게 눈에 보인다.

왜 하필 거대 음수인가 — cvttsd2si와 NaN

이 음수 거대값의 근원은 부동소수점 변환 명령 하나다. JS의 숫자는 IEEE-754 배정밀도 64비트다.

출처: Wikimedia Commons, CC BY-SA 4.0

double을 32비트 정수로 자를 때 TurboFan은 cvttsd2si(convert-with-truncation)를 쓴다. 이 명령은 입력이 정수 범위를 벗어나거나 NaN이면 "integer indefinite" 값 0x80000000(INT_MIN)을 돌려준다. 평소엔 무해하다 — JS ToInt32는 NaN을 0으로 바꿔야 하므로 컴파일러가 앞뒤에 "NaN이면 0" 보정을 깐다. 그런데 typer가 "이 값은 절대 NaN 아님"을 증명해버리면 그 보정이 죽은 코드로 제거되고, 보정 없는 cvttsd2si 한 방만 남는다. 런타임에 진짜 NaN이 들어오면 INT_MIN이 그대로 산술 체인을 타고 흘러 -1073741813 같은 값이 된다. Math.exp의 오타입이 "NaN 보정 제거"라는 기계어 결정으로 번역되는 순간이다. 이게 3편 내내 "발산값"이라 부르는 재료의 정체다.

여기서 한 가지가 중요하다 — 이 발산은 --allow-natives-syntax로 강제 최적화했을 때만 나는 게 아니라, natives 없이 자연 hot-loop 티어업으로도 똑같이 난다. 서버 runner.py는 natives 없이 ./out/d8 <payload>를 돌리니, 이건 원격 실행 모델에서도 살아 있는 어긋남이다. 재료는 진짜다. 문제는 이 음수 거대값을 받아 OOB로 바꿔줄 곳이 없다는 것.

트리거 — 왜 패치된 타입이 적용되려면 "추론을 꺼야" 하나

패치는 JSCallTyper(일반 호출의 타입 추론)를 건드린다. 그런데 TurboFan은 Math.exp(x) 같은 잘 알려진 수학 함수를 보면, 보통 그걸 일반 JSCall로 두지 않고 NumberExp 같은 전용 노드로 낮춰버린다(speculative inlining). 그 전용 노드는 NaN을 정직하게 다루는 자기만의 타입 규칙을 써서, 패치된 JSCallTyper를 안 탄다 — 즉 버그가 안 난다.

그래서 트리거의 핵심은 그 speculative inlining을 막아 Math.exp를 generic JSCall로 유지시키는 것이다. 호출 지점을 다형(polymorphic)으로 만들면 된다 — 핫루프에서 숫자 인자와 문자열 인자를 섞어 부르면(g(1.1)와 g("x") 교대), V8이 "이 인자 타입을 못 믿겠다"며 전용 노드로 못 내리고 일반 JSCall로 남긴다. 그제서야 패치된 JSCallTyper가 적용돼 Math.exp의 반환이 "NaN 아님"으로 굳고, 진짜 Math.exp(NaN)=NaN과 어긋난다. 1편의 f(NaN)=111도, 위 발산도 전부 이 다형 트릭으로 speculation을 끈 상태에서 나온다.

🚪 출구 점검 — 비표준 sink를 하나씩

발산한 INT_MIN(또는 no-NaN 믿음 자체)을 흘려보낼 수 있는 CheckBounds 바깥 sink를, 카테고리별로 전부 d8에 때려봤다.

전부 음성이다. 두 갈래는 실측을 따로 보일 가치가 있다.

fill / copyWithin — CheckBounds가 없어서 더 안전했다

가장 기대를 건 건 fill/copyWithin이었다. 이들은 인덱스를 CheckBounds로 막지 않으니, typer를 속이면 검사가 통째로 없을 줄 알았다. 그래서 발산값(typer=11, 런타임 거대음수)을 start/end로 직접 넣어봤다.

../extracted/deploy/out/d8 p3_fill_clamp.js

전부 클램프다. a.fill(7.7, v)는 v가 거대음수라 max(len+v, 0)=0으로 접혀 배열 전체를 채우고(in-range), fill(7.7, v, v+1)·copyWithin은 빈 범위로 접혀 아무 일도 안 한다. 배열 길이는 4 그대로, 크래시 없음. 즉 이 빌트인들은 CheckBounds를 안 쓰는 대신 인자를 ToInteger로 정규화하고 start < 0 ? max(len+start,0) : min(start,len)으로 클램프한다 — CheckBounds보다 더 부드럽지만, OOB로는 더 단단히 막는다. --trace-turbo-reduction으로 봐도 인덱스 경로에 NumberMin/NumberMax 클램프 노드가 살아 있다.

Math sweep — 발산은 진짜지만 값이 갇혀 있다

다른 갈래는 Math 연산이다. no-NaN을 믿으면 min/max/sign이 NaN 보정(SilenceNaN)을 생략한다 — 발산이 실재한다. 그런데 그 발산이 쓸모가 없다.

../extracted/deploy/out/d8 p3_math_sweep.js

Math.max(0, exp(NaN))은 0, Math.min(exp(NaN), 5)는 5. maxsd/minsd는 한 피연산자가 NaN이면 다른 피연산자를 고르므로(IEEE 규칙), 결과가 항상 클램프 상수 쪽으로 떨어진다. 즉 런타임 값이 typer가 증명한 범위 안에 갇힌다 — [0..5]를 못 벗어난다. OOB 인덱스도, 거대 길이도 못 만든다. 양쪽을 다 clamp하면 NaN이 소모돼 발산이 사라지고, 한쪽만 하면 typer 범위가 무한이라 in-bounds다. 어느 쪽이든 sink로 못 쓴다.

TypedArray·DataView — 경계도 detach도 가드된다

TypedArray/DataView는 다른 결의 sink다. 여기엔 길이 검사 우회 말고도 detach UAF(버퍼를 떼어낸 뒤 옛 포인터로 접근)라는 고전 각이 있다. 둘 다 봤다. ta.set(src, offset)·ta.subarray(a, b)의 오프셋은 전부 길이로 검사·클램프되고, 발산값을 넣어도 OOB가 아니라 RangeError거나 빈 뷰다. detach 쪽은 — ArrayBuffer를 떼면 백킹 데이터 포인터가 무효가 되는데, TurboFan이 detach 가능성을 알면 접근 직전에 detach 가드를 깐다(jnscs.cc의 typed-array 빌더가 buffer를 다시 로드해 검사). no-NaN 믿음으로는 그 가드를 못 지운다. typer 버그가 건드리는 건 값의 범위지 버퍼의 생사가 아니라서, detach 경로엔 손이 안 닿는다.

요소종류 전이 — grow도 결국 CheckBounds

마지막 후보는 요소종류 전이(element-kind transition)다. PACKED_SMI → PACKED_DOUBLE → PACKED_ELEMENTS로 배열의 표현이 바뀔 때, 또는 MaybeGrowFastElements로 백킹을 키울 때, 종류 가드나 grow 검사를 no-NaN으로 깨면 double↔tagged 혼동이나 grow 생략이 날까 기대했다. 안 난다 — grow 경로도 결국 인덱스를 CheckBounds로 거치고(그게 abort 하드닝 대상), 종류 전이는 값의 종류(Smi냐 double이냐)를 보지 NaN 여부를 안 본다. Math.exp(NaN)이 주는 canonical NaN은 여전히 double이라 종류 가드를 못 흔든다.

나머지 후보까지 전부 같은 운명이다. 흥미로웠던 삽질 둘을 토글에 남긴다.

💡 핵심 발견 — 의도된 길마저 막혀 있었다

여기서부터가 3편의 진짜 수확이다. Math.exp/expm1 같은 typer 버그의 교과서적 의도 해법은 인덱스가 아니라 길이를 만드는 것이다 — Quick-Maffs(linz04)·Bug-1051017이 쓴 length-construction. 발산한 값을 new Array(v)에 넣어, typer는 "용량 11짜리 작은 배열"이라 믿고 백킹 스토어를 작게 잡는데 런타임 v는 거대해서 length > capacity 불일치가 나면, 그 배열로 백킹 스토어 밖을 읽고 쓸 수 있다. 위 발산 체인이 정확히 그 재료(typer 11 / 런타임 INT_MIN)를 만든다.

왜 length-construction이 인덱스보다 강한가

인덱스 공격(a[v])은 한 번 배열 밖을 건드리고 끝이며, 그마저 CheckBounds가 막는다. 반면 length-construction은 지속적인 OOB 배열 그 자체를 만든다. JSArray는 헤더에 length 필드를, 별도 FixedDoubleArray(백킹 스토어)에 실제 원소를 둔다. 정상이라면 length ≤ capacity다. 그런데 typer가 길이를 "11"로 믿어 capacity 11짜리 백킹을 잡았는데 런타임 길이가 거대값이 되면, arr[12], arr[100], arr[1000]이 전부 *"length 안"*으로 통과해 백킹 밖 인접 힙을 읽고 쓴다 — 한 번이 아니라 임의 횟수의 상대 R/W다. 게다가 CheckBounds는 인덱스를 length 와 비교하는데 그 length가 이미 거대하니, 검사 자체가 무의미해진다(인덱스가 진짜로 length보다 작으니까). 그래서 이게 typer 값-발산 버그의 정석 승급 경로다 — 발산을 한 번만 길이에 꽂으면, 그 뒤로는 평범한 배열 접근이 곧 OOB가 된다.

그래서 그대로 태워봤다 — new Array(v) 한 뒤 arr[0]=1.1, 그리고 길이를 확인.

../extracted/deploy/out/d8 --allow-natives-syntax qm_newarray.js 2>&1 | head -9

arr.length = 11. arr[100]·arr[1000] 둘 다 undefined. %DebugPrint로 봐도 elements: FixedDoubleArray[11], length: 11 — length와 capacity가 11로 일치한다. 불일치가 없다. 의도된 sink가 막혀 있다.

왜 막혔나 — 패치의 사정거리

패치를 다시 보면 답이 나온다. patches/v8.patch가 건드린 건 typer.cc(Math.exp → PlainNumber)와 d8 락다운뿐이다. length-construction이 OOB가 되려면 JSCreateArray를 낮추는 js-create-lowering.cc가 length를 Constant(capacity)로 고정하는 보호를 제거해야 하는데, 이 패치는 거기를 안 건드렸다. 그래서 ReduceJSCreateArray의 세 분기가 전부 안전하게 남아, 런타임 길이가 거대해도 capacity와 묶여 불일치가 안 생긴다.

정리하면 이 문제의 진짜 구조는 이거다 —

typer 버그는 살아 있는데, 그 버그를 받아줄 의도된 sink의 보호는 패치가 안 풀었다.

버그(typer.cc)와 sink 보호(js-create-lowering.cc)가 서로 다른 파일에 있고, 패치는 앞쪽만 열었다. 1·2편에서 본 CheckBounds 하드닝은 모든 인덱스 경로를 막고, length-construction 보호는 그 대안 경로를 막는다. 공개 기법이 노리는 두 출구가 양쪽 다 닫혀 있는 셈이다.

🔬 다음 한 수 — 배포 바이너리를 직접 부검

여기서 의심이 하나 생긴다. 위 판정은 전부 소스 commit 6538a20a 를 읽고 한 것이고, length 보호가 "소스에 있다"는 사실이다. 그런데 실제 채점 서버가 돌리는 건 소스가 아니라 빌드된 d8 바이너리다. 빌드 플래그·인라이닝·최적화 차이로 소스에는 있는 보호가 바이너리엔 다르게 들어갔을 가능성 — 즉 패치↔바이너리 불일치 는 배제하지 못했다.

그래서 남은 1순위는 추측이 아니라 확인이다 —

1. 배포 out/d8의 ReduceJSCreateArray / JSCreateArray 낮춤 코드를 직접 디스어셈블해, length = Constant(capacity) 보호가 바이너리에 실재하는지 본다. 구체적으로는 new Array(v)를 도는 핫함수를 만들어 --print-opt-code(또는 --trace-turbo로 그래프를 떠 objdump)로 길이 계산 부분을 추적한다. 찾을 것은 — 할당 직전에 length를 capacity 상수로 덮어쓰는 명령(mov [rax+0xC], <const> 같은 JSArray length 스토어)이 있는지, 아니면 런타임 v가 그대로 length 필드로 들어가는지다. 후자면 불일치가 살아 있다는 뜻.
2. 보호가 바이너리에 없거나 소스와 다르면 → 의도 sink가 실제 타겟에선 열려 있을 수 있고, 위 발산 체인이 그대로 라이브 OOB가 된다. (빌드 플래그·인라이닝·PGO 차이로 소스↔바이너리가 갈리는 건 드물지만 0은 아니다.)
3. 그 외에, 소스를 다 훑어도 0이 아닌 가능성 — 공개되지 않은 비-CheckBounds sink (이 빌드 특유의 인라인 빌트인 내부 길이 연산 등). 다만 전수 점검 결과 이건 낮게 본다(체감 15% 미만).

4편 註: 결국 길은 3번이었다 — 바이너리 부검이 아니라, 소스에서 덜 본 reducer(Array.prototype.at())가 비-CheckBounds sink였다. 3편이 "공개되지 않은 sink"라 적은 그 15%가 실제로 열려 있었던 셈. 그래서 다음 편의 출발점은 바이너리가 아니라 js-call-reducer.cc 재독이 됐다.

이건 다음 편(또는 직접 더 파볼) 출발점이다. 어긋남은 이미 손에 있으니, 첫 OOB 한 칸만 열리면 된다.

🪜 OOB만 열리면, 그 뒤는 그대로

2편 끝에서 매핑해둔 후반부 체인은 sink가 무엇이든 동일하다. 첫 OOB read/write가 생기는 순간:

1. PACKED_DOUBLE 배열과 객체 배열을 인접시켜 압축 포인터를 누출 → addrof / fakeobj
2. ArrayBuffer의 backing_store(@JSArrayBuffer+0x14)를 덮어 → 케이지 내부 임의 R/W
3. WasmInstanceObject.jump_table_start(@instance+~0x60, 케이지 밖 raw RWX)를 찾아 셸코드 기입 → 샌드박스 탈출
4. execve("./flag_reader-<md5>") (서버 cwd /home/pwn) → flag

전부 자연 티어업에서 동작해야 하지만(원격 제약), 발산 자체는 이미 자연 티어업으로 검증됐다. 막힌 건 오직 1번의 입구다.

🗂️ 시도 요약 — 무엇을 두드렸고 어디서 막혔나

한 줄 결론: 인덱스 출구도, 길이 출구도, 비표준 출구도 (소스 기준) 전부 닫혔다. 단 — 두 번째 행의 at에 대한 판정이 성급했다는 게 4편에서 드러난다.

📝 결론 — 정직한 음성 결과

3편의 결과는 이렇다.

• 표준 경로(인덱스 CheckBounds 제거)는 닫혔다 — 2편에서 소스로 확정.
• 비표준 출구(fill/copyWithin·foldable 빌트인·TypedArray·요소종류·표현형 변환)도 전부 닫혔다 — 이 편에서 d8 실측으로 전수 확인.
• 의도된 sink(new Array length-construction)마저 닫혀 있다 — 패치가 typer.cc만 열고 js-create-lowering의 길이 보호는 안 풀었기 때문.
• 그런데 버그(어긋남) 자체는 살아 있다 — 자연 티어업에서 INT_MIN으로 발산.

즉 이건 "어렵다"가 아니라, 재료는 있는데 받아줄 그릇이 (소스 기준으로) 전부 막힌 상태다. 그래서 다음 한 수는 추측을 늘리는 게 아니라, 배포 바이너리에서 그 그릇의 보호가 진짜 박혀 있는지 부검하는 것 — 거기서 소스와 바이너리가 갈리면 길이 다시 열린다.

플래그는 아직이다. 하지만 막힌 지점이 "감"이 아니라 패치 파일·소스 줄·d8 실측·바이너리 부검 대상으로 정확히 좁혀졌다. typer 버그를 끝까지 따라가면, 화려한 익스보다 이런 지도가 먼저 나온다.

뒷이야기 (4편): 이 "전부 닫힘" 결론엔 구멍이 하나 있었다 — 여기서 본 출구는 전부 a[i](bracket)와 CheckBounds 계열이었는데, 빌트인 reducer로 가는 길을 제대로 안 봤다. Array.prototype.at()은 CheckBounds가 아니라 fold 가능한 NumberLessThan 두 개로 경계를 검사한다 — 그래서 무가드 OOB read가 실제로 열린다. 그 반전은 4편에서.

🛡️ 방어 관점 — 이 문제가 증명하는 것

이 챌린지는 역설적으로 계층 방어가 실제로 작동한다는 증거다.

• typer 버그(Math.exp 오타입)는 한 줄로 들어왔지만, 그것만으로는 아무것도 안 된다.
• CheckBounds를 절대 제거하지 않고 in-bounds 증명 시 abort로 바꾸는 하드닝이 인덱스 출구를 막고,
• JSCreateArray의 length=capacity 보호가 길이 출구를 막는다.

공격자가 한 출구를 열어도(여기선 typer를 속이는 데까지 성공) 다음 계층이 메모리 침범으로의 승급을 끊는다. 브라우저 보안의 "버그 ≠ 익스플로잇" 원칙이 소스 라인 단위로 구현된 모습이다. 그리고 출제자 입장에서 보면, 이 문제가 다이아 1인 이유도 여기 있다 — 의도된 sink 보호까지 살아 있어, 푸는 쪽은 남은 단 하나의 비표준 입구를 찾아야 한다.

📚 참고

• V8 소스 commit 6538a20a (11.2.214.14) — compiler/simplified-lowering.cc, compiler/js-native-context-specialization.cc, compiler/js-create-lowering.cc
• linz04, Quick-Maffs — 동일 Math.exp NaN 버그류의 length-construction 해법
• Project Zero / chromium bug 1051017 — length-construction OOB
• doar-e, Circumventing Chrome's hardening of typer bugs
• 이 시리즈: 1편 — 버그·트리거 · 2편 — 소스 부검 · 4편 — .at() 반전