Pixel 10을 위한 0-click 익스플로잇 체인

우리는 최근 Google Pixel 9에 대한 익스플로잇 체인 (exploit chain)을 발표했으며, 이를 통해 단 두 번의 익스플로잇만으로 zero-click 컨텍스트에서 Android의 root 권한까지 도달하는 것이 가능하다는 것을 입증했습니다. Dolby 0-click 취약점은 2026년 1월에 패치되기 전까지 Android 전반에 걸쳐 존재했습니다. Pixel 9에 대한 익스플로잇 체인을 보유하고 있었지만, 우리는 Pixel 10을 위한 유사한 익스플로잇 체인을 작성하는 것이 가능한지 확인하고 싶었습니다.

Dolby 익스플로잇 업데이트

CVE-2025-54957에 대한 우리의 익스플로잇을 수정하는 것은 상당히 간단했습니다. 필요한 변경 사항의 대부분은 Pixel 9에서 타겟팅했던 특정 라이브러리 버전에 대해 계산된 오프셋 (offset)을 Pixel 10의 라이브러리에 대한 유사한 오프셋으로 업데이트하는 작업이었습니다. 유일한 난관은 (어떤 syncframes에 오프셋이 포함되어 있는지 더 잘 문서화해 두었으면 좋았겠다는 아쉬움을 제외하면) Pixel 10이 -fstack-protector 대신 RET PAC를 사용한다는 점이었습니다. 이는 __stack_chk_fail을 코드로 덮어쓸 수 없음을 의미했습니다. 약간의 시행착오 끝에, 우리는 dap_cpdp_init를 사용했습니다. 이는 디코더가 초기화될 때 한 번 호출된 후 다시는 호출되지 않으므로, 기능적인 문제 없이 덮어쓸 수 있는 초기화 코드입니다. 업데이트된 Dolby UDC 익스플로잇은 여기서 확인할 수 있습니다. 이 익스플로잇은 패치되지 않은 기기(SPL 2025년 12월 또는 그 이전)에서만 작동합니다.

BigWave의 제거, VPU의 추가

체인의 로컬 권한 상승 (local privilege escalation) 링크를 Pixel 10으로 포팅하는 것은 BigWave 드라이버가 이 기기에 탑재되지 않았기 때문에 불가능했습니다. 하지만 mediacodec SELinux 컨텍스트의 /dev/vpu에서 새로운 드라이버가 확인되었습니다. 이 드라이버는 비디오 디코딩 가속을 위해 설계된 Tensor G5 칩의 Chips&Media Wave677DV 실리콘과 상호작용하는 데 사용됩니다. 오픈 소스 C 파일 내의 주석에 따르면, 이 드라이버는 BigWave 드라이버를 구축한 것과 동일한 개발자 그룹에 의해 개발 및 유지 관리됩니다. Jann Horn과 협력하여 우리는 이 VPU 드라이버를 2시간 동안 감사(auditing)했고, 매우 이례적인 취약점을 발견했습니다.

WAVE521C(이전 세대의 Chips&Media 칩)를 위한 업스트림 Linux 드라이버와 달리, WAVE677DV를 위한 Pixel 드라이버는 V4L2("Video for Linux API")와 통합되지 않습니다. 대신, 이 드라이버는 사용자 공간(userspace)이 칩의 MMIO 레지스터 인터페이스를 매핑할 수 있도록 허용하는 것을 포함하여, 칩의 하드웨어 인터페이스를 사용자 공간에 직접 노출합니다. 이 드라이버는 주로 장치 메모리 매핑을 설정하고, 전원 관리(power management)를 수행하며, 사용자 공간이 칩으로부터의 인터럽트(interrupt)를 대기할 수 있도록 합니다.

커널 취약점의 성배 (The Holy Grail of Kernel Vulnerabilities)

특히 이 버그는 익스플로잇(exploit)하기가 매우 간단하다는 점에서 우리의 주의를 끌었습니다:

static int vpu_mmap(struct file *fp, struct vm_area_struct *vm)
{
unsigned long pfn;
...

이 mmap 핸들러는 VPU 하드웨어의 MMIO 레지스터 영역을 사용자 공간(userland) 가상 주소 공간으로 매핑하기 위해 사용되도록 설계되었습니다. 이 영역은 특정 물리 메모리 주소 범위 내에 포함되어 있습니다. 이 과정에서 핸들러는 VMA의 크기에만 기반하여 remap_pfn_range를 호출하며, 이 레지스터 영역의 크기에 대해서는 전혀 제한을 두지 않습니다. 이는 mmap 시스템 콜(syscall)에서 레지스터 영역보다 더 큰 크기를 지정함으로써, 호출자가 VPU 레지스터 영역의 물리 주소부터 시작하여 원하는 만큼의 물리 메모리를 사용자 공간으로 매핑할 수 있음을 의미합니다. 커널 이미지 전체(.text 및 .data 영역 포함)는 VPU 레지스터 영역보다 더 높은 물리 주소에 위치하므로, 이 버그를 통해 사용자 공간에서 커널에 접근하고 이를 수정할 수 있습니다.

이 시점에서, 공격자는 커널 코드 실행 (kernel code execution) 권한을 얻기 위해 단순히 임의의 커널 함수를 덮어쓰거나, 실제로 원하는 그 어떤 프리미티브 (primitive)라도 획득할 수 있습니다. Pixel에서는 커널이 항상 동일한 물리 주소에 위치하며, 따라서 VPU 메모리 영역과 커널 사이의 오프셋 (offset)이 항상 알려진 값이라는 사실 덕분에 이 과정은 더욱 쉬워집니다. 그러므로 매핑된 물리 메모리에서 커널을 스캔할 필요조차 없습니다. VMA 길이를 충분히 크게 설정한다는 가정하에, mmap에 의해 반환된 주소와 비교하여 커널이 정확히 어디에 있는지 알 수 있기 때문입니다.

이 취약점을 통해 커널에 대한 임의 읽기-쓰기 (arbitrary read-write)를 달성하는 데는 단 5줄의 코드만 필요했으며, 이 문제에 대한 완전한 익스플로잇 (exploit)을 작성하는 데는 하루 미만의 노력이 필요했습니다.

패치 과정 (Patch Process)

저는 2025년 11월 24일에 이 버그를 보고했으며, Android VRP는 이 이슈의 심각도를 High로 평가했습니다. 이는 Pixel 9에서 권한 상승 (privilege escalation)을 위해 사용했던 BigWave 버그(동일한 보안 영향력을 가짐)가 처음에 Moderate 심각도로 평가되었던 것을 고려하면 개선된 결과입니다. 이는 이러한 유형의 버그가 분류 (triage)되고 패치되는 방식에 있어 의미 있고 긍정적인 변화를 나타냅니다. 해당 취약점은 최초 보고 71일 후인 2월 Pixel 보안 게시판(security bulletin)에서 패치되었습니다. 제가 보고한 Android 드라이버 버그가 벤더가 취약점을 처음 인지한 후 90일 이내에 패치된 것은 이번이 처음이라는 점을 감안하면 이는 눈에 띄게 빠른 속도입니다.

결론 (Conclusion)

결론 (Conclusion)

이 연구로부터 얻을 수 있는 긍정적인 면과 부정적인 면이 모두 존재합니다. Project Zero의 핵심 목표는 개별적인 버그 수정(bug fixes)을 넘어 시스템적인 개선을 유도하는 것이며, 이는 더 나은 개발 프로세스와 더 회복력 있는 코드베이스(codebases)에 영향을 미쳐 최종 사용자(end-users)를 위한 보안 향상으로 이어지게 하는 것입니다. 이번 VPU 취약점(vulnerability) 처리는 Android의 분류 파이프라인(triage pipeline)에서 명확한 진전이 있었음을 보여주는데, 이 버그는 이전의 BigWave 이슈들보다 훨씬 짧은 기간 내에 초기 조치(remediation)가 이루어졌기 때문입니다. 심각한 취약점들이 효율적으로 패치되도록 보장하려는 Android의 노력은 수많은 Android 기기들을 보호하는 데 도움이 될 것입니다.

동시에, 이번 사례는 Android 드라이버(drivers)에서 더욱 철저하게 견고하고 보안을 의식하는 코드(security-aware code)가 지속적으로 필요함을 강조합니다. 제가 BigWave의 버그들을 보고했을 때, 저는 개발자들이 다른 드라이버들에 대해서도 명백한 보안 이슈가 있는지 평가하도록 자극하기를 바랐습니다. 하지만 5개월이 지난 후에도 우리는 코드베이스(codebase)를 대충 검토(audit)하기만 해도 즉시 눈에 띌 정도로 심각하고 매우 얕은 취약점을 그들의 VPU 드라이버에서 발견했습니다. 드라이버 보안을 강화하는 것은 안전한 Android 생태계를 보장하기 위한 중요한 우선순위로 남아 있으며, 우리는 이러한 종류의 취약점이 최종 사용자에게 도달하는 것을 방지하기 위한 선제적인 노력으로서 벤더(vendors)들이 소프트웨어 개발 관행을 개선할 것을 계속해서 강력히 권고하고 있습니다.

보안 보고서들은 종종 제품 팀이 놓친 복잡한 문제들을 발견하곤 하지만, 소프트웨어 벤더들이 소프트웨어 제품, 특히 보안에 치명적인(security-critical) 제품들이 합리적으로 취약점이 없는 상태로 출시되도록 필요한 조치를 취하는 것과, 소프트웨어 팀이 소프트웨어 보안, 코드 감사(code auditing), 그리고 취약점 패치(vulnerability patching)에 대해 선제적인 접근 방식을 취하는 것이 중요합니다.