#hardening

3편은 "남은 출구를 전수로 두드렸지만 다 닫혔다"로 끝났다. 4편은 그 결론을 내 손으로 뒤집는 기록이다 — 3편이 본 sink는 전부 bracket 접근(`a[i]`)과 CheckBounds 계열이었는데, 딱 하나 안 본 게 있었다. `Array.prototype.at()`. 이건 별도 reducer(js-call-reducer.cc)라 경계검사를 CheckBounds가 아니라 fold 가능한 NumberLessThan 두 개 + bare LoadElement 로 한다. 패치가 그 파일을 안 건드려서 그대로 살아있고, reshape로 typer를 속이면 두 가드가 접혀 무가드 OOB read가 진짜로 열린다(자연 티어업, exit0, 결정적). 다만 store 짝이 없어 write는 여전히 막혀 있고(bracket=trap, TypedArray/fill/with 전멸, a.length는 치유), read→write 다리는 addrof/fakeobj뿐이다. 포인터 압축이 왜 reader 타입을 가르는지, 그리고 그 fakeobj 부트스트랩(타입-매칭 인접)이 왜 nursery monoculture에 막히는지 — V8 reducer 구조부터 쉘 스샷까지 한 단계씩.

2편은 "표준 값-range 경로(CheckBounds 제거)는 11.2에서 닫혔다"까지였다. 3편은 그 뒤 — CheckBounds를 거치지 않는 *비표준 출구*를 하나하나 전부 두드린 기록이다. fill/copyWithin, foldable 빌트인, TypedArray·DataView, 요소종류 전이, 표현형 변환까지 후보 sink를 전수로 d8에 때려봤고 전부 정화/트랩/in-range로 죽었다. 그리고 가장 뜻밖의 발견 — 이 버그류의 *의도된* 해법인 new Array(len) length-construction마저 이 빌드에선 막혀 있다. 패치가 typer.cc만 건드리고 js-create-lowering의 길이 보호는 안 풀어서다. 어긋남은 살아있는데(자연 티어업에서 INT_MIN으로 발산) 받아줄 sink가 없다. 끝으로 남은 한 수 — 배포 바이너리 직접 부검.

1편에서 타입혼동을 인덱스까지 살려 보냈지만 거기서 트랩으로 끊겼다. 2편은 "왜 트랩인가"를 V8 11.2 소스로 부검한다. CheckBounds가 기계어가 되는 경로, typer가 인덱스를 in-bounds로 증명하면 검사를 제거가 아니라 abort로 바꾸는 무조건 하드닝(kAbortOnOutOfBounds), 그리고 doar-e식 우회를 정조준해 막아둔 element-access 빌더의 두 번째 CheckBounds까지 — 소스 주석째로 들고 본다. 끝으로, 같은 시기 하드닝 켜진 V8을 실제로 뚫은 익스(구글 v8CTF·openECSC)가 왜 값-range typer 버그가 아니라 length/element-kind를 직접 손상시키는 다른 버그 클래스를 쓰는지 대조한다.

오랜만에 Next.js 사이트를 직접 뒤적거리며 보안 점검을 했다. 발견한 문제들과 어떻게 고쳤는지 실제 커맨드 결과랑 같이 정리.