▲

Pixel 10용 0-click 익스플로잇 체인

 (projectzero.google)
1P by GN⁺ 4시간전 | ★ favorite | 댓글 1개
  • Pixel 10 체인은 패치 전 Android 전반에 있던 Dolby 0-click 취약점을 첫 단계로 사용하고, 새 로컬 권한 상승 경로를 추가함
  • Pixel 9 체인의 BigWave 드라이버는 Pixel 10에 없어 이식할 수 없었고, 대신 Tensor G5의 /dev/vpu가 공격 표면이 됨
  • VPU 드라이버는 userspace에 MMIO 레지스터 인터페이스를 직접 노출했고, 2시간 감사만으로 치명적인 mmap 버그가 발견됨
  • remap_pfn_range가 레지스터 크기가 아니라 VMA 크기만 기준으로 매핑해, 커널 .text와 .data 읽기·쓰기가 가능해짐
  • 취약점은 2025년 11월 24일 보고 후 71일 만에 패치됐고, Android 드라이버 보안 강화가 여전히 필요함

Pixel 10 0-click 체인 구성

  • Google Pixel 9에서 0-click 문맥에서 Android root까지 두 개의 익스플로잇으로 도달한 익스플로잇 체인을 바탕으로, Pixel 10에서도 유사한 체인을 구성함
  • Dolby 0-click 취약점은 2026년 1월 패치 전까지 Android 전반에 존재했으며, Pixel 10 대상 체인에서도 첫 단계로 쓰임
  • Pixel 9의 로컬 권한 상승 단계였던 BigWave 드라이버는 Pixel 10에 포함되지 않아 그대로 이식할 수 없었고, Pixel 10의 /dev/vpu 드라이버가 새로운 공격 표면이 됨

Dolby 익스플로잇 업데이트

  • CVE-2025-54957용 기존 익스플로잇을 Pixel 10에 맞추는 작업은 대부분 Pixel 9 라이브러리 기준 오프셋을 Pixel 10 라이브러리의 대응 오프셋으로 갱신하는 수준이었음
  • Pixel 10은 -fstack-protector 대신 RET PAC를 사용해 __stack_chk_fail을 덮어쓸 수 없었음
  • 여러 시도 끝에 디코더 초기화 때 한 번 호출되고 다시 호출되지 않는 초기화 코드 dap_cpdp_init을 덮어쓰는 방식이 사용됨
  • 업데이트된 Dolby UDC 익스플로잇은 여기에 공개됐으며, 2025년 12월 SPL 이하의 패치되지 않은 기기에서만 동작함

BigWave 제거와 VPU 추가

  • Pixel 10에는 BigWave 드라이버가 없어 기존 Pixel 9 체인의 로컬 권한 상승 단계를 포팅할 수 없었음
  • mediacodec SELinux 문맥에서 접근 가능한 /dev/vpu 드라이버가 새로 보였고, 이는 Tensor G5 칩의 비디오 디코딩 가속용 Chips&Media Wave677DV 실리콘과 상호작용하는 데 쓰임
  • 공개 C 파일의 주석상 이 드라이버는 BigWave 드라이버를 만든 개발자들과 같은 그룹이 개발·유지하는 것으로 나타남
  • Jann Horn과 함께 2시간 동안 VPU 드라이버를 감사한 결과, 매우 예외적인 취약점이 발견됨
  • 이전 Chips&Media 칩인 WAVE521C용 업스트림 Linux 드라이버와 달리, Pixel의 WAVE677DV 드라이버는 V4L2(“Video for Linux API”)와 통합되지 않음
  • Pixel 드라이버는 칩의 하드웨어 인터페이스를 userspace에 직접 노출하며, userspace가 칩의 MMIO 레지스터 인터페이스를 매핑할 수 있게 함
  • 드라이버의 주요 역할은 장치 메모리 매핑 설정, 전원 관리, userspace의 칩 인터럽트 대기 지원임

핵심 커널 취약점

  • 해당 버그는 익스플로잇이 매우 단순한 취약점이었음
  • 문제의 mmap 핸들러는 VPU 하드웨어의 MMIO 레지스터 영역을 userland 가상 주소 공간에 매핑하는 코드임
  • remap_pfn_range 호출이 레지스터 영역 크기로 제한되지 않고 VMA 크기만 기준으로 수행됨
  • 공격자는 mmap 시스템 호출에서 레지스터 영역보다 큰 크기를 지정해, VPU 레지스터 영역의 물리 주소부터 원하는 만큼의 물리 메모리를 userland에 매핑할 수 있음
  • 커널 이미지 전체가 VPU 레지스터 영역보다 높은 물리 주소에 위치하므로, 이 버그로 커널의 .text와 .data 영역에 접근하고 수정할 수 있음
  • Pixel에서는 커널이 항상 같은 물리 주소에 위치해, VPU 메모리 영역과 커널 사이의 오프셋이 항상 알려진 값임
  • 충분히 큰 VMA 길이를 지정하면 매핑된 물리 메모리에서 커널을 스캔하지 않아도 mmap이 반환한 주소 기준으로 커널 위치를 정확히 알 수 있음
  • 이 취약점으로 커널 임의 읽기·쓰기를 달성하는 데는 코드 5줄이 필요했고, 전체 익스플로잇 작성에는 하루 미만이 걸림
  • 임의의 커널 함수를 덮어써 커널 코드 실행을 얻거나 원하는 프리미티브를 구성할 수 있음

패치 처리

  • 취약점은 2025년 11월 24일 보고됐고, Android VRP는 이 문제를 High 심각도로 평가함
  • Pixel 9 권한 상승에 사용된 BigWave 버그는 보안 영향이 동일했지만 초기에 Moderate로 평가됐으므로, 이번 평가는 개선된 처리로 볼 수 있음
  • 취약점은 최초 보고 후 71일 만에 2월 Pixel 보안 게시판에서 패치됨
  • Android 드라이버 버그가 벤더에 최초 보고된 뒤 90일 이내에 패치된 것은 처음으로 평가됨
  • 이 처리 과정에서 유사한 유형의 버그를 분류하고 패치하는 Android의 대응이 의미 있게 개선됐음이 드러남

보안상 의미

  • VPU 취약점 대응은 Android의 분류 파이프라인이 개선됐음을 보여주며, 이전 BigWave 문제보다 훨씬 짧은 기간 안에 초기 수정이 이뤄짐
  • 심각한 취약점을 효율적으로 패치하려는 Android의 노력은 많은 Android 기기 보호에 도움이 됨
  • 동시에 Android 드라이버에는 더 철저하고 보안 의식이 반영된 코드가 계속 필요함
  • BigWave 버그 보고 이후 관련 개발자들이 다른 드라이버의 명백한 보안 문제를 점검하길 기대했지만, 5개월 뒤 VPU 드라이버에서 얕은 감사만으로도 즉시 드러나는 심각한 취약점이 발견됨
  • Android 생태계의 안전성을 위해 드라이버 보안 강화는 여전히 중요한 우선순위임
  • 벤더는 취약점이 최종 사용자에게 도달하지 않도록 소프트웨어 개발 관행을 사전에 개선해야 하며, 특히 보안에 중요한 제품은 출시 시점부터 합리적으로 취약점이 적은 상태여야 함
  • 소프트웨어 팀은 보안, 코드 감사, 취약점 패치에 대해 사전 예방적 접근을 취해야 함

함께 보면 좋은 글 β

▲
GN⁺ 4시간전  [-]
Hacker News 의견들

  • Pixel 9 버그/익스플로잇 링크를 따라가 보니, AI 기능 때문에 메시지를 사용자가 열기 전에 미디어를 디코딩해야 해서 0클릭 공격 표면이 늘어난다는 내용이 있었음
    이런 교훈은 이미 얻은 것 아닌가 싶음. 내가 요청하지 않았는데 SMS를 읽고 무언가를 처리하지 말라는 얘기임

    • 우리가 배웠어야 한다는 교훈이 정확히 무엇인지 모르겠음
      사용자들은 풍부한 메시징 기능이 있는 휴대폰을 고름. iPhone에서는 iMessage가, 이후 Android에서는 RCS가 따라잡기 전까지 이게 큰 판매 포인트였음
    • 그것만으로도 충분하지 않음. 사용자가 메시지와 상호작용하기 전까지 이미지를 파싱하지 않는 이메일 클라이언트를 생각해 보면, 클릭해서 수상하다고 깨닫는 순간 이미 복잡하고 버그 많은 장치가 실행된 뒤임
      개인적으로 가장 황당했던 건, 어떤 BigTech 웹메일에서 거의 확실히 악성 첨부파일이 든 매우 수상한 메시지를 스팸으로 표시했더니, 피싱은 아니었으므로 다른 선택지가 없었는데, “친절하게도” 내 로컬 브라우저에서 구독 해지 링크를 허락도 없이 열어버린 일임. 보안과 프라이버시에 민감한 맥락에서 그런 기능을 작성하고, 리뷰하고, 승인하고, 배포하려면 어느 정도의 무능과 조직 기능장애가 필요한지 상상하기 어려움
    • Google이 Android를 소유하지만, Google은 사용자에게 관심이 없음. 그들의 고객은 광고 게시자임
      0-day도 크게 중요하지 않음. 대안이 사실상 iPhone 정도뿐이고, Huawei도 지역에 따라 가능할 뿐이라 신경 쓸 이유가 별로 없음. 우리는 새 휴대폰 OS와 하드웨어 계층이 urgently 필요함
    • 최근 “AI Security” 발표를 들었는데, 요지는 “AI로 들어오고 나가는 입력을 무비판적으로 삼킬 것이고, 그건 보안 문제지만 할 수 있는 건 없으니 사후처리나 하라”에 가까웠음
      “위협 행위자가 내부 문서를 업데이트하면 그걸로 AI에 영향을 줄 수 있다”는 말도 포함됐는데, 위협 행위자가 문서를 업데이트하고 있다면 이미 침해된 것임. 여기서 말하는 건 “Wikipedia 반달” 수준이 아님
    • 사용자가 메시지를 열게 만드는 건 별로 높은 장벽이 아님
      사용자 입장에서 어떤 메시지를 열지 조심해야만 하는 건 받아들이기 어렵다. 이메일 첨부파일에서 책임을 사용자에게 떠넘겨 봤고, 그 결과는 재앙이었다고 봐도 공정함. 악성 첨부파일은 아마도 악성코드 배포의 가장 중요한 경로임

  • “Android 드라이버 버그를 보고한 뒤 벤더가 취약점을 처음 인지한 시점부터 90일 안에 패치된 것은 이번이 처음이라 특히 빠르다”는 문구를 보니 Google에 대한 인상은 좋아지지만, 동시에 나머지 Android 생태계는 좀 무서워짐
    Apple의 대응 시간은 어떨지 궁금함

    • Android 벤더들은 오래전부터 업데이트로 악명이 높았음. 그 이유 중 하나는 휴대폰 회사들이 서로 차별화하려고 기본 Android UI를 포크해서, 브랜드별 기능과 환각적인 UI 비전을 제공하려 하기 때문이라고들 함
      하지만 그러면 순정 Android 업데이트가 나왔을 때 마이그레이션 작업이 엄청나게 커짐
    • 예전에 Apple에 보안 버그를 보고한 적이 있음. 몇 년 전 일이지만 패치까지 대략 6개월 걸렸던 것으로 기억함
      더 안정적인 개념 증명을 만들기 위해 몇 번 오갔고, 100% 재현되는 개념 증명을 제출한 뒤로는 아마 2개월 정도였음
    • 현재 Android 기기의 42%가 미패치 상태라는 점을 보면 [1], 연구 내용을 공개해서 전부 취약하게 만드는 결정은 흥미로움
      [1] https://gs.statcounter.com/android-version-market-share
      [2] https://www.cybersecurity-insiders.com/survey-reveals-over-1...
    • 유명 브랜드 Android 기기라면 OS 보안 업데이트는 기대할 수 있음. 1차 벤더가 직접 빌드해서 푸시할 수 있기 때문임
      하지만 드라이버와 펌웨어 보안 업데이트는 장담하기 어렵다. 이런 업데이트는 종종 상위 공급업체에서 나와야 하는데, 그들이 문제를 고칠 의지가 있을 수도 없을 수도 있음. 작은 브랜드는 저가 Android 기기를 팔고 업데이트를 아예 하지 않는 경우가 많음

  • 약간 관련해서, 최근 공개 익스플로잇 비율이 실제로 올라간 건지, 아니면 AI가 공격·방어 보안 도구로 주목받다 보니 뉴스에 더 자주 보이는 건지 궁금함
    이틀에 한 번꼴로 Linux, Windows, 모바일, 모두가 쓰는 흔한 도구 등에서 뭔가 새로 나오는 느낌임

    • 1부를 행간까지 읽어보면, 문제의 코드는 AI 기능 때문에 도입됐고 익스플로잇은 사람이 찾은 것임
      https://projectzero.google/2026/01/pixel-0-click-part-1.html
      그러니 AI 사용은 버그를 늘리고, 사람이 그걸 골라내야 하는 셈임
    • 지난 주말에 직접 분석해 봤는데, 2024년에는 공개된 CVE가 하루 대략 100개였음. 4월에는 하루 약 200개에 도달함
      2023년 이전으로 거슬러 올라가면 공개 CVE의 두 배 증가 주기는 대략 4~4.5년이었는데, 그 이후로는 약 2년임. 확실히 급격히 늘어났음
    • 오픈소스 보안 버그를 관리하는 사람들에 따르면 보고가 크게 늘었음. 처음에는 대부분 가짜에 가까운 저품질 보고였지만, 이제는 실제로 유효한 보고도 훨씬 많아졌다고 함
    • 순전히 추측이고 보안 연구자는 아니지만, AI가 낮은 품질의 악용 가능한 공격 표면을 늘리는 동시에 보안 연구자의 작업 속도를 높이는 촉진제 역할도 하는 것 같음
      잘 쓰면 훌륭하지만, 못 쓰면 정말 나쁘다는 뜻임
    • 최근 몇 주 사이 널리 쓰이는 도구 벤더들에게 꽤 심각한 문제 몇 건을 보고했는데, 인정받기까지 평소보다 더 어려웠음
      대응 팀들이 보고 폭주로 과부하 상태라고 들었음

  • 내 생각이 맞는지 누가 한 번 확인해 줬으면 함. 아래 정확한 프롬프트를 gpt 5.5 xhigh에 넣었음

    does this look right to you? don't do any searches or check memory, just think through first principles

static int vpu_mmap(struct file fp, struct vm_area_struct vm) { unsigned long pfn; struct vpu_core core = container_of(fp->f_inode->i_cdev, struct vpu_core, cdev); vm_flags_set(vm, VM_IO | VM_DONTEXPAND | VM_DONTDUMP); / This is a CSRs mapping, use pgprot_device */ vm->vm_page_prot = pgprot_device(vm->vm_page_prot); pfn = core->paddr >> PAGE_SHIFT; return remap_pfn_range(vm, vm->vm_start, pfn, vm->vm_end-vm->vm_start, vm->vm_page_prot) ? -EAGAIN : 0; }

    웹 검색 없이도 문제를 정확히 짚어냈음. 특정 함수만이 아니라 코드베이스 덩어리 전체를 프롬프트에 넣는 식으로 더 포괄적으로 해보고 싶음. 보안 익스플로잇을 잡아낼 잠재 능력은 있어 보임. 그렇다면 이게 애초에 어떻게 릴리스됐는지가 궁금함. 장난감 예제라는 건 알지만 더 배우고 싶음

    • 그건 공정한 테스트는 아님. 프롬프트가 버그를 찾으라고 직접 말하지는 않아도 모델을 꽤 강하게 유도하고 있음
      현재 모델이 mythos만큼 좋다고 주장했던 스레드에서 나왔던 반론과 기본적으로 같음
    • 일화로, fragnesia.c와 이후 문제를 고치기 위한 패치를 넣어봤는데 완전히 새로운 취약점을 발견하지는 못했지만, 같은 근본 버그를 악용하는 새 방법 2가지는 찾은 것 같았음
      Claude 구독만 가진 멍청한 나 같은 사람이 해본 결과라는 점을 생각하면 꽤 인상적임
    • 이것만으로는 취약점 찾기에 실제로 쓸 수 있는 방식인지 판단할 수 없음. 전체 코드에 돌렸을 때 거짓 양성이 얼마나 나올지 모르기 때문임
      다른 말로 하면 https://en.wikipedia.org/wiki/Base_rate_fallacy일 수 있음
    • 웹 검색을 하지 않았다는 걸 어떻게 아는지 궁금함
    • 인터넷 접근이 없는 claude Opus 4.7에 코드를 붙여넣고 함수가 무엇을 하는지만 설명해 달라고 했는데, 설명하면서 버그도 짚었음. 버그를 찾으라고 말하지 않았음

      Observations & Potential Issues
      A few things worth flagging:

      1. No bounds checking on the mapping size. Userspace controls vm_end - vm_start and vm->vm_pgoff. Here vm_pgoff is ignored entirely and the size is trusted blindly. If the VPU's register block is, say, 64KB but userspace requests a 1MB mapping, the driver will happily map 1MB of physical address space starting at core->paddr — potentially exposing whatever hardware happens to live at adjacent physical addresses. A defensive check would be:
        봇이 모든 오픈소스 프로젝트의 PR을 나오는 즉시 스캔할 수 있는 시대라면, 70일 릴리스 주기는 익스플로잇의 광범위한 사용을 막기에 빠르게 부족해질 것임

  • 훌륭한 버그 보고서임. 커널 전문가는 전혀 아니고 10년 넘게 전에 조금 읽어본 정도인데도, 따라가며 무슨 일이 벌어지는지 이해할 수 있었음
    이게 정말 심각한 버그였고 찾는 데 일이 그렇게 많아 보이지 않았다는 점 때문에, 다른 어떤 위험이 숨어 있을지 무서워짐. 또 최근 많은 보안 이슈가 AI로 찾아지고 있는데, 이 보고서를 보며 두 가지를 생각하게 됨. 전문성은 여전히 엄청나게 가치 있고, 더 틈새일수록 더 가치가 큼. 그리고 AI가 아직 지배하지 못하는 틈새가 많이 남아 있음

  • iPhone 탈옥은 어디 간 건지 모르겠음. 꽤 오랫동안 아무것도 못 봤는데 무슨 일이 벌어지는 건가? 내가 놓친 건지, 아니면 실제로 가능한 게 없는 건지 궁금함
    Apple이 어떻게 하든 대단하긴 한데, 현재 흐름상 시간문제인지 아니면 실제로 어떤 변화가 있는 건지 알고 싶음

    • Apple의 보안 태세는 Lockdown Mode, 메모리 태깅, 보안 할당자 덕분에 Android보다 상당히 나음
      여기서 일부를 읽어볼 수 있음: https://security.apple.com/blog/memory-integrity-enforcement...
    • 요즘은 재부팅 후에도 살아남는 익스플로잇이 거의 불가능함. 그리고 탈옥을 가능하게 하는 익스플로잇은 이제 익스플로잇 체인 전체가 필요하고, 그 가치는 상당히 높으며 공개되는 즉시 패치됨
      그래서 예전 iPhone 탈옥 장면 같은 건 이제 불가능함
    • “탈옥”이 다른 플랫폼의 소프트웨어 취약점과 같은 수준의 검증을 받지 않는 게 늘 짜증났음

  • AI가 NSO 같은 업체들의 사업에 어떤 영향을 줬는지 증거가 있을까? 그들을 쓸모없게 만드는지, 아니면 오히려 초강력화시키는지 궁금함

    • 자세한 건 모르지만, AI가 판을 크게 바꾸고 있고 0-day라는 형태의 많은 “자본”이 사라졌을 것 같음
      그렇다면 NSO와 그 비슷한 회사들을 제외한 모두에게 좋은 소식임

  • 비슷한 문제를 겪어본 적이 있음. 해결책은 합리적으로 보이지만, 주장하는 성능 개선에는 회의적임

  • 하드웨어 비디오 디코딩을 지원하기 위한 V4L2 개선사항들이 오랫동안 병합 대기 중이었고, 지금은 메인라인 커널에 들어간 것 같음
    아마 사람들이 그렇게 오래 기다리고 싶지 않았던 듯함

  • Project Zero도 Android에 버그를 정식 창구로 보고하고, Android VRP 심각도 분류를 상대해야 한다는 게 의외임
    그냥 Android 사무실로 걸어가서 얼굴 보고 버그 중요성을 설득할 수 있을 거라고 늘 생각했음

    • “정상적인” 방식이 너무 고통스럽다고 느꼈다면, 아마 그 방식 자체를 고치도록 Project Zero가 다음으로 시도했을 것임
    • 그건 Android가 Project Zero의 말을 들어준다는 가정에 기대고 있음
답변달기