Skip to content

CVE-2025-2783-chrome-mojo-pseudo-handle-sandbox-escape.md

Latest commit

 

History

History
198 lines (151 loc) · 11.2 KB

CVE-2025-2783-chrome-mojo-pseudo-handle-sandbox-escape.md

File metadata and controls

198 lines (151 loc) · 11.2 KB
Raw

Chrome Mojo/ipcz 의사 핸들 샌드박스 탈출 (CVE-2025-2783)

메타데이터

항목 내용
CVE ID CVE-2025-2783
영향 구성요소 Windows의 Chrome Mojo/ipcz 핸들 전달 경로
영향 제품 Google Chrome for Windows 134.0.6998.177 미만
취약점 유형 Windows 의사 핸들 검증 누락으로 인한 Sandbox Escape
공개/수정 2025-03-26 공개, Chrome 134.0.6998.177/.178 및 Extended Stable 134.0.6998.178에 수정 포함
악용 상태 CISA KEV에 2025-03-27 등재
분석 기준 NVD·CISA 공개 메타데이터, Microsoft API 문서, Chromium BSD-3-Clause 공개 수정 diff의 정적 분석. PoC·공격 코드는 실행하지 않음

개요

CVE-2025-2783은 Windows용 Chrome의 Mojo/ipcz IPC 경로가 Windows의 의사(pseudo) 핸들을 일반 핸들처럼 넘길 수 있었던 문제다. NVD는 이를 악성 파일을 통한 Chrome 샌드박스 탈출로 분류하며, CISA는 실제 악용 위험 때문에 KEV에 추가했다.

학습 포인트는 숫자처럼 보이는 HANDLE 값이 항상 객체 권한을 가진 실제 핸들은 아니라는 점이다. Windows에는 현재 프로세스·현재 스레드를 가리키는 의사 핸들이 있다. 이 값을 신뢰 경계를 넘어 전달한 뒤 수신 프로세스 문맥에서 복제하면, 원래의 숫자가 수신 측 권한으로 해석될 수 있다. Chrome의 수정은 이 위험한 값을 한 곳에서 식별하고, ipcz가 송신·수신·복제하는 모든 관문에서 거부하도록 바꿨다.

사전 지식

Chrome의 프로세스 격리와 핸들 전달

Chrome은 웹 콘텐츠를 처리하는 renderer를 낮은 권한의 sandbox에 두고, 더 높은 권한이 필요한 작업은 browser/broker 등 별도 프로세스에 맡긴다. 이 구조에서 IPC는 단순한 데이터 전달이 아니라 권한이 붙은 운영체제 객체를 전달하는 통로가 될 수 있다.

웹 콘텐츠 / renderer (낮은 권한)
        │
        │ Mojo/ipcz 메시지와 플랫폼 핸들
        ▼
browser 또는 broker (더 높은 권한)
        │
        ▼
Windows 객체·파일·프로세스·IPC 서비스

안전한 설계의 불변식은 "낮은 권한 프로세스가 보낸 핸들 표현이 broker 자신의 권한을 뜻하도록 재해석되어서는 안 된다"이다. 따라서 수신자가 값을 실제 OS 객체 핸들로 복제하거나 사용하기 전에, 그 값의 종류와 소유 문맥을 확인해야 한다.

실제 핸들과 의사 핸들은 같은 정수처럼 보여도 의미가 다르다

Windows의 실제 핸들은 특정 프로세스의 핸들 테이블에 있는 객체 참조다. 반면 GetCurrentProcess와 GetCurrentThread는 현재 문맥을 가리키는 의사 핸들을 반환한다. Microsoft 문서는 DuplicateHandle이 이 두 의사 핸들을 실제 프로세스 또는 스레드 핸들로 변환한다고 설명한다. 또한 이 둘 외의 의사 핸들은 DuplicateHandle로 복제하지 말아야 한다고 명시한다.

실제 핸들:     "이 프로세스의 표에서 찾는 객체 참조"
의사 핸들:     "현재 실행 문맥의 프로세스/스레드"라는 특수 표기

같은 숫자 값이더라도
송신자 문맥에서의 의미 ≠ 수신자 문맥에서의 의미

이 차이는 단일 프로세스 안에서는 편리하다. 하지만 IPC 메시지의 비신뢰 값이 의사 핸들로 해석되면, "보낸 쪽의 값"이 아니라 "받은 쪽 자신"을 가리키는 값으로 바뀔 수 있다. 핸들은 권한을 담는 capability이므로 이 재해석은 문자열 파싱 오류보다 훨씬 큰 보안 결과를 낳는다.

Mojo/ipcz의 플랫폼 핸들 경계

Mojo는 Chrome 프로세스 사이의 통신 계층이고, ipcz는 그 전송을 지원하는 구성요소다. Windows에서 플랫폼 핸들을 전송하려면 메시지의 핸들 표현을 직렬화하고, 상대 프로세스 쪽에서 다시 해석하며, 필요할 경우 DuplicateHandle로 유효한 수신 측 핸들을 만들어야 한다.

이 흐름에서는 세 곳 모두 같은 검증을 지켜야 한다.

  1. 보낼 값을 메시지 형식으로 바꾸기 전
  2. 메시지에서 값을 다시 HANDLE로 해석한 직후
  3. OS에 실제 핸들 복제를 요청하기 직전

하나만 확인하면 다른 경로가 우회점이 될 수 있다. CVE-2025-2783의 수정은 이 검증을 개별 호출에 흩어두지 않고 공통 의사 핸들 판정으로 통일했다.

취약점 분석

확인된 사실

  • NVD는 Windows용 Chrome 134.0.6998.177 미만의 Mojo에서 잘못된 핸들 제공으로 샌드박스 탈출이 가능했다고 기록한다.
  • CISA KEV는 이 항목을 Google Chromium Mojo Sandbox Escape 취약점으로 등재했다.
  • Bug 405143032에 연결된 공개 Chromium 안정 브랜치 수정은 제목 그대로 sentinel handle의 송수신을 막는다. 수정은 -1부터 -12 범위의 알려진 의사/특수 핸들을 식별한다.
  • 같은 수정은 ipcz transport의 송신 전, 수신 데이터 decode 직후, 그리고 PlatformHandleInTransit의 DuplicateHandle 전에서 의사 핸들을 거부한다. 단위 시험은 현재 프로세스·현재 스레드 의사 핸들은 참이고 null은 거짓임을 확인한다.

패치 전: 데이터 값이 수신자 권한으로 의미를 바꾸는 경계

공개 수정 diff는 sentinel 값을 ipcz로 보내거나 받지 말아야 한다고 명시한다. 다만 Chrome이 실제 공격에서 받은 전체 메시지 형식, 초기 renderer 장악 방식, 복제에 사용된 세부 권한 마스크는 공개되지 않았다. 따라서 아래 그림은 공개 diff와 Windows API 의미를 결합한 일반화된 위험 모델이다.

패치 전의 위험 모델

낮은 권한 프로세스가 제공한 HANDLE 비트열
                 │
                 ▼
          ipcz 메시지 전달
                 │
                 ▼
수신 측이 sentinel/pseudo 값인지 확인하지 않고 decode 또는 복제
                 │
                 ▼
Windows가 수신 프로세스의 "현재 프로세스/스레드" 문맥으로 해석할 가능성
                 │
                 ▼
낮은 권한 renderer가 원래 받으면 안 되는 capability에 연결
                 │
                 ▼
Chrome sandbox 경계 약화 또는 탈출

핵심 오류는 메모리 손상이 아니라 capability의 출처를 잃는 논리 오류다. 정상적인 핸들 전달은 "어느 프로세스의 어떤 객체에 대한 어떤 권한인가"를 보존해야 한다. 의사 핸들은 그 질문에 독립적으로 답하지 못하고 실행 중인 호출자 문맥에 의존한다. 그러므로 비신뢰 IPC 입력으로 허용하면 수신자의 권한을 간접 참조하게 된다.

왜 DuplicateHandle이 보안 경계가 되는가

DuplicateHandle은 한 프로세스의 핸들을 다른 프로세스에서 쓸 수 있는 실제 핸들로 만들 수 있다. Microsoft 문서에 따르면 현재 프로세스·현재 스레드 의사 핸들은 이 호출에서 실제 핸들로 변환된다. 따라서 broker가 더 넓은 권한을 가진 상황에서 의사 핸들을 평범한 전송 값으로 처리하면, 복제 연산 자체가 권한 확대의 지점이 된다.

이는 IPC 수신자가 "이 값은 음수가 아니면 유효하다" 같은 형식 검증만 해서는 부족하다는 사례다. 값이 문법적으로 유효한지와, 낮은 권한 발신자가 그 capability를 수신자에게 요청할 권한이 있는지는 별도의 검증이다.

수정 방법

Chromium의 공개 수정은 base::win::IsPseudoHandle로 Windows 의사 핸들 판정을 공통화했다. 알려진 문제 범위인 -1부터 -12의 음수 값을 의사 핸들로 보고, 실제 핸들이 그 범위에 들어갈 가능성은 사실상 없다는 전제 아래 차단한다. 그리고 ipcz의 송신·수신·복제 경로가 모두 이 판정을 사용한다.

패치 후의 방어 흐름

플랫폼 핸들 입력
       │
       ▼
IsPseudoHandle?
  │ 예                         │ 아니오
  ▼                            ▼
메시지 송신/해석/복제 거부       정상적인 소유자·권한 검증 경로
  │                            │
  └──────── 오류 처리 ─────────┘

이 수정의 장점은 특정 DuplicateHandle 호출 하나만 고친 것이 아니라, 플랫폼 핸들이 ipcz 경계에 들어오고 나가는 지점을 모두 방어한다는 점이다. Chrome 사용자는 Windows Stable 134.0.6998.177/.178 이상(Extended Stable은 .178 이상)으로 업데이트해야 한다. 조직에서는 Chrome의 실행 파일 버전뿐 아니라 관리 도구가 실제 업데이트 적용을 완료했는지 점검해야 한다.

PoC 관련 언급

이 CVE는 CISA KEV에 등재됐지만, 이 보고서는 공개 PoC나 공격 체인을 내려받거나 실행하지 않았다. 초기 renderer 코드 실행, IPC 메시지 구성, 권한 마스크, 후속 코드 주입 방식은 방어 원리를 이해하는 데 필요한 범위를 넘어가므로 재현 절차로 제공하지 않는다.

미해결/불확실 지점

  • Chromium 이슈 405143032의 세부 내용은 공개 접근으로 확인할 수 없어, 실제 공격 메시지와 트리거 조건을 특정하지 않는다.
  • 공개 diff는 sentinel 핸들을 막는 정확한 수정 위치를 보여 주지만, 실제 악용 체인에서의 모든 발신자·수신자 프로세스 조합과 권한 마스크를 공개하지 않는다.
  • NVD 설명의 "malicious file"이 초기 renderer 실행을 어떤 방식으로 얻었는지는 이 CVE의 공개 패치만으로 확인되지 않는다.

더 살펴볼 점

  • IPC 설계에서 숫자 값과 capability의 소유자·권한을 분리해 검증하려면 어떤 타입 모델이 적절할까?
  • OS의 편의용 sentinel 값은 다른 신뢰 경계를 넘을 때 왜 일반 데이터보다 먼저 거부해야 할까?

참고 자료

참고 외 별도 확인 링크

아래 웹 글은 해당 콘텐츠의 재사용 조건이 이 저장소의 보수적 본문 근거 기준과 명확히 맞는지 확인하지 못해, 본문 작성 근거로 사용하지 않고 추가 확인 링크로만 둔다.