자바스크립트 배열 한 칸 바깥, V8이 넘어선 경계선 이야기

이미지 출처: CISA KEV

브라우저는 우리가 하루 중 가장 오래 켜 두는 프로그램임. 메일도 보고, 사내 그룹웨어도 열고, 심지어 방화벽 관리 콘솔까지 브라우저로 들어감. 그런데 그 브라우저 안에서 남의 자바스크립트를 초당 수천 줄씩 실행하고 있다는 사실은 자주 잊게 됨. CVE-2026-87491은 바로 그 지점, Chromium의 자바스크립트 엔진인 V8에서 발생한 Out of Bounds Write(경계 밖 쓰기) 취약점임.

핵심 요약

• Chromium V8 엔진의 경계 밖 쓰기 결함으로, 악성 페이지 방문만으로 렌더러 메모리가 조작될 수 있음
• 브라우저 단독 취약점이라기보다 샌드박스 탈출·권한 상승과 엮이는 연쇄 공격의 1단계로 보는 편이 맞음
• 방어의 핵심은 자동 업데이트 강제, 브라우저 버전 인벤토리 확보, 그리고 재시작하지 않는 사용자를 찾아내는 일

1. Out of Bounds Write가 V8에서 갖는 의미

경계 밖 쓰기는 이름 그대로 할당된 메모리 범위를 넘어선 위치에 값을 기록하는 결함임. 길이가 10인 배열에 11번째 칸을 쓰는 상황을 떠올리면 개념은 단순함. 문제는 그 단순한 개념이 V8 안에서는 훨씬 무겁게 작동한다는 점임.

• V8은 자바스크립트를 그대로 해석하지 않고 JIT 컴파일로 기계어를 만들어 냄. 이 과정에서 "이 배열 길이는 항상 10이다" 같은 최적화 가정을 세우고, 그 가정을 믿고 경계 검사(bounds check)를 통째로 생략함.
• 공격자가 그 가정을 깨뜨리는 코드 패턴을 만들면, 컴파일러가 지워 버린 검사 자리에 그대로 구멍이 생김.
• 렌더러 프로세스 힙에는 함수 포인터, 객체 메타데이터, 다른 탭에서 넘어온 데이터 구조가 같이 놓여 있음. 한 칸을 잘못 쓰는 순간 임의 읽기·쓰기로 확장되는 경로가 열림.

그래서 V8 계열 메모리 결함은 "브라우저가 죽는다" 수준에서 끝나지 않고, 대부분 렌더러 코드 실행까지 목표로 삼음. 공격 재현 코드는 여기서 다루지 않지만, 구조만 알아도 왜 이 계열 패치가 항상 급한지는 충분히 이해됨.

2. 실제 공격 흐름은 어떻게 생겼나

이런 결함이 실전에서 쓰일 때의 모양은 거의 정형화되어 있음. 순서대로 정리하면 이럼.

• 1단계 — 유입: 피싱 링크, 악성 광고(멀버타이징), 혹은 정상 사이트에 삽입된 스크립트. 사용자는 클릭 한 번밖에 하지 않음.
• 2단계 — 렌더러 장악: V8 결함으로 렌더러 프로세스 안에서 코드 실행. 이 시점까지는 아직 샌드박스 안임.
• 3단계 — 샌드박스 탈출: 별도의 커널 드라이버나 브라우저 브로커 프로세스 취약점을 엮어서 샌드박스 밖으로 나감.
• 4단계 — 지속성 확보: 여기서부터는 평범한 엔드포인트 침해와 똑같음. 스케줄러 등록, 자격 증명 탈취, 내부망 정찰.

방어자 입장에서 반가운 소식이 하나 있다면, 2단계에서 3단계로 넘어가는 벽이 꽤 두껍다는 점임. 사이트 격리(Site Isolation)와 샌드박스가 제대로 켜져 있으면 렌더러 하나를 잃어도 즉시 전면 침해로 이어지지는 않음. 그래서 이 구간의 설정을 건드리지 않는 것이 생각보다 중요한 방어임.

3. 탐지 관점 — 무엇을 볼 것인가

솔직히 말하면 렌더러 안에서 벌어지는 익스플로잇 자체를 EDR이 직접 보기는 어려움. 그래서 탐지는 대부분 "결과의 흔적"을 잡는 쪽으로 설계함.

• 브라우저의 비정상 자식 프로세스: chrome.exe나 msedge.exe가 powershell.exe, cmd.exe, rundll32.exe, mshta.exe를 띄우는 순간은 거의 언제나 조사 대상임. 렌더러 익스플로잇 이후 단계에서 가장 먼저 드러나는 신호임.
• 반복되는 렌더러 크래시: 익스플로잇은 한 번에 성공하지 않음. 힙 정렬(heap grooming)이 어긋나면 탭이 죽음. 특정 단말에서 짧은 시간 안에 브라우저 크래시가 몰린다면 정황 증거로 볼 만함. Windows 이벤트 로그의 애플리케이션 오류(1000번대)를 브라우저 프로세스로 필터링해 두면 유용함.
• 렌더러 프로세스의 네트워크 시도: 정상적으로는 네트워크 서비스 프로세스가 통신을 담당함. 렌더러가 직접 외부로 나가려는 흔적은 이상 신호임.
• 브라우저 프로필 디렉터리의 이상 변화: 확장 프로그램이 조용히 추가되거나 Preferences 파일이 예상 밖 시점에 바뀌는 것도 후속 단계에서 자주 보임.
• 프록시·DNS 로그: 짧은 수명의 도메인, 신규 등록 도메인으로의 첫 접속. 익스플로잇 킷은 여전히 이 패턴을 벗어나지 못함.

4. 완화 — 우선순위대로

이 계열 취약점의 대응은 화려한 기술보다 지루한 운영이 승부를 가름. 순서대로 하면 이럼.

• 업데이트를 강제하고, 재시작까지 확인함. Chromium 계열은 패치를 받아도 브라우저를 재시작해야 적용됨. 몇 주째 탭 300개를 켜 둔 채 재시작을 미루는 단말이 조직마다 반드시 있음. 그룹 정책의 RelaunchNotification과 RelaunchNotificationPeriod로 강제 재시작 기한을 두는 편을 개인적으로 추천함.
• 버전 인벤토리를 실제로 수집함. "자동 업데이트 켜 뒀으니 되겠지"는 검증이 아님. 자산 관리 도구나 EDR 질의로 브라우저 버전 분포를 뽑아 보면, 뒤처진 단말 비율에 놀라는 경우가 많음. Chrome, Edge, Whale, 그리고 Electron 기반 사내 앱까지 같이 봐야 함. Electron 앱은 V8을 품고 있으면서도 자동 업데이트가 없는 경우가 흔함.
• 사이트 격리와 샌드박스를 끄지 않음. 성능 튜닝이나 특정 업무 시스템 호환 때문에 관련 플래그를 해제해 둔 조직이 의외로 있음. 한번 점검해 볼 가치가 충분함.
• 고위험 사용자에게는 추가 층을 둠. 임원, 개발자, 관리자 계정 사용자에게는 강화된 보안 모드나 원격 브라우저 격리를 검토할 만함. 전사 적용은 부담스러워도 대상을 좁히면 현실적임.
• 확장 프로그램을 허용 목록으로 관리함. 브라우저 공격면은 엔진만이 아님. 오히려 확장 쪽이 더 조용하고 오래감.

5. 학습자에게 남기고 싶은 것

브라우저 취약점을 공부하다 보면 처음엔 익스플로잇 기법 이름들에 압도되기 쉬움. 근데 계속 보다 보니 결국 반복되는 건 몇 가지 축이더라. 메모리 안전성, 최적화가 만드는 가정, 그리고 그 가정이 깨지는 지점. V8이든 다른 엔진이든 이 구조는 크게 다르지 않음.

실습으로 이어 가고 싶다면 순서를 이렇게 잡는 걸 개인적으로 추천함. 먼저 자바스크립트 배열의 내부 표현과 elements kind 개념을 읽어 보고, 그 다음 JIT가 어떤 조건에서 경계 검사를 제거하는지 컴파일러 관점 자료를 보고, 마지막으로 공개된 패치 커밋 diff를 읽어 보는 것. 패치 diff는 정말 좋은 교재임. "여기에 검사 한 줄이 추가되었다"는 사실 자체가 취약점의 본질을 한 줄로 요약해 주니까.

정리하면 이럼. 이번 건은 특별히 새로운 종류의 위협이라기보다, 브라우저 패치 주기를 조직이 제대로 굴리고 있는지 확인하는 시험지에 가까움. 오늘 자기 조직의 브라우저 버전 분포를 한 번만 뽑아 보자. 생각보다 할 일이 명확해질 것임. 다들 각자 환경에서 확인해 보고, 재시작 강제 정책 어떻게 운영하고 계신지 댓글로 공유해 주면 같이 배워 보아요!