Rantai eksploit 0-click untuk Pixel 10

• Rantai Pixel 10 menggunakan kerentanan Dolby 0-click yang sebelumnya ada di seluruh Android sebelum ditambal sebagai tahap awal, lalu menambahkan jalur eskalasi hak akses lokal yang baru
• Driver BigWave pada rantai Pixel 9 tidak ada di Pixel 10 sehingga tidak bisa dipindahkan, dan sebagai gantinya /dev/vpu pada Tensor G5 menjadi permukaan serangan
• Driver VPU secara langsung mengekspos antarmuka register MMIO ke userspace, dan hanya dengan audit selama 2 jam ditemukan bug mmap yang fatal
• remap_pfn_range melakukan pemetaan berdasarkan ukuran VMA alih-alih ukuran register, sehingga memungkinkan baca-tulis pada kernel .text dan .data
• Kerentanan ini dilaporkan pada 24 November 2025 dan ditambal dalam 71 hari, tetapi penguatan keamanan driver Android masih tetap diperlukan

---

Komposisi rantai 0-click Pixel 10

• Berdasarkan rantai eksploit yang mencapai Android root dari konteks 0-click di Google Pixel 9 dengan dua eksploit, rantai serupa juga disusun untuk Pixel 10
• Kerentanan Dolby 0-click ada di seluruh Android hingga patch Januari 2026, dan juga digunakan sebagai tahap pertama pada rantai yang menargetkan Pixel 10
• Driver BigWave yang menjadi tahap eskalasi hak akses lokal pada Pixel 9 tidak disertakan di Pixel 10 sehingga tidak bisa langsung dipindahkan, dan driver /dev/vpu di Pixel 10 menjadi permukaan serangan baru

Pembaruan eksploit Dolby

• Pekerjaan menyesuaikan eksploit yang sudah ada untuk CVE-2025-54957 ke Pixel 10 pada dasarnya sebatas memperbarui offset berbasis library Pixel 9 ke offset yang sesuai di library Pixel 10
• Pixel 10 menggunakan RET PAC alih-alih -fstack-protector, sehingga __stack_chk_fail tidak bisa ditimpa
• Setelah beberapa percobaan, dipakai metode menimpa kode inisialisasi dap_cpdp_init yang dipanggil sekali saat inisialisasi decoder dan tidak dipanggil lagi sesudahnya
• Eksploit Dolby UDC yang telah diperbarui dipublikasikan di sini, dan hanya berfungsi pada perangkat yang belum ditambal dengan SPL Desember 2025 atau lebih lama

BigWave dihapus dan VPU ditambahkan

• Karena Pixel 10 tidak memiliki driver BigWave, tahap eskalasi hak akses lokal dari rantai Pixel 9 yang lama tidak bisa diporting
• Driver /dev/vpu yang dapat diakses dari konteks SELinux mediacodec terlihat sebagai komponen baru, dan digunakan untuk berinteraksi dengan silikon Chips&Media Wave677DV untuk akselerasi dekode video pada chip Tensor G5
• Dari komentar pada file C yang dipublikasikan, driver ini tampak dikembangkan dan dipelihara oleh grup yang sama dengan para pengembang driver BigWave
• Hasil audit driver VPU selama 2 jam bersama Jann Horn menemukan kerentanan yang sangat tidak biasa
• Berbeda dengan driver Linux upstream untuk chip Chips&Media WAVE521C sebelumnya, driver WAVE677DV di Pixel tidak terintegrasi dengan V4L2 (“Video for Linux API”)
• Driver Pixel secara langsung mengekspos antarmuka hardware chip ke userspace, sehingga userspace dapat memetakan antarmuka register MMIO milik chip
• Peran utama driver adalah menyiapkan pemetaan memori perangkat, manajemen daya, dan dukungan agar userspace dapat menunggu interupsi chip

Kerentanan kernel inti

• Bug tersebut adalah kerentanan dengan eksploitasi yang sangat sederhana
• Handler mmap yang bermasalah adalah kode untuk memetakan area register MMIO hardware VPU ke ruang alamat virtual userland
• Pemanggilan remap_pfn_range dilakukan hanya berdasarkan ukuran VMA tanpa dibatasi ukuran area register
• Penyerang dapat menentukan ukuran yang lebih besar daripada area register pada system call mmap, sehingga bisa memetakan memori fisik sebanyak yang diinginkan mulai dari alamat fisik area register VPU ke userland
• Karena seluruh image kernel berada pada alamat fisik yang lebih tinggi daripada area register VPU, bug ini memungkinkan akses dan modifikasi ke area .text dan .data milik kernel
• Di Pixel, kernel selalu berada pada alamat fisik yang sama, sehingga offset antara area memori VPU dan kernel selalu merupakan nilai yang diketahui
• Dengan menentukan panjang VMA yang cukup besar, posisi kernel bisa diketahui secara tepat dari alamat yang dikembalikan mmap tanpa perlu memindai kernel dalam memori fisik yang dipetakan
• Hanya diperlukan 5 baris kode untuk mencapai baca-tulis kernel arbitrer dengan kerentanan ini, dan penulisan keseluruhan eksploit selesai dalam waktu kurang dari sehari
• Penyerang bisa menimpa fungsi kernel arbitrer untuk mendapatkan eksekusi kode kernel atau menyusun primitif yang diinginkan

Proses patch

• Kerentanan ini dilaporkan pada 24 November 2025, dan Android VRP menilai masalah ini dengan tingkat keparahan High
• Bug BigWave yang digunakan untuk eskalasi hak akses di Pixel 9 memiliki dampak keamanan yang sama tetapi awalnya dinilai Moderate, sehingga penilaian kali ini bisa dilihat sebagai penanganan yang lebih baik
• Kerentanan ini ditambal di buletin keamanan Pixel edisi Februari 71 hari setelah laporan awal
• Ini dinilai sebagai pertama kalinya bug driver Android ditambal dalam waktu 90 hari setelah pertama kali dilaporkan ke vendor
• Dalam proses penanganan ini, terlihat bahwa respons Android dalam mengklasifikasikan dan menambal bug dengan tipe serupa telah meningkat secara bermakna

Implikasi keamanan

• Penanganan kerentanan VPU menunjukkan bahwa pipeline klasifikasi Android telah membaik, dan perbaikan awal dilakukan jauh lebih cepat daripada kasus BigWave sebelumnya
• Upaya Android untuk menambal kerentanan serius secara efisien membantu melindungi banyak perangkat Android
• Pada saat yang sama, driver Android masih membutuhkan kode yang lebih teliti dan lebih sadar keamanan
• Setelah laporan bug BigWave, sempat diharapkan para pengembang terkait akan memeriksa masalah keamanan yang jelas pada driver lain, tetapi 5 bulan kemudian ditemukan kerentanan serius pada driver VPU yang langsung terlihat bahkan dengan audit dangkal
• Demi keamanan ekosistem Android, penguatan keamanan driver tetap menjadi prioritas penting
• Vendor harus lebih dulu memperbaiki praktik pengembangan perangkat lunak agar kerentanan tidak sampai ke pengguna akhir, dan terutama untuk produk yang penting bagi keamanan, sejak peluncuran kondisinya harus sudah cukup minim kerentanan
• Tim perangkat lunak harus mengambil pendekatan proaktif terhadap keamanan, audit kode, dan patch kerentanan

[GN⁺]

Opini Hacker News

• Setelah mengikuti tautan bug/eksploit Pixel 9, ada penjelasan bahwa karena fitur AI, media harus didekode sebelum pengguna membuka pesannya, sehingga permukaan serangan 0-click bertambah
  Rasanya pelajaran seperti ini seharusnya sudah kita dapatkan. Maksudnya, jangan membaca SMS dan memproses sesuatu darinya tanpa saya minta

  • Saya tidak yakin apa tepatnya pelajaran yang seharusnya sudah kita ambil
    Pengguna memilih ponsel dengan fitur perpesanan yang kaya. Di iPhone, iMessage adalah nilai jual besar, lalu di Android hal itu dikejar oleh RCS
  • Itu saja tidak cukup. Bayangkan klien email yang tidak mem-parsing gambar sampai pengguna berinteraksi dengan pesan; pada saat Anda mengklik dan sadar ada yang mencurigakan, rangkaian perangkat yang kompleks dan penuh bug sudah lebih dulu berjalan
    Secara pribadi, hal paling konyol yang pernah saya alami adalah ketika saya menandai pesan yang sangat mencurigakan dengan lampiran yang hampir pasti berbahaya sebagai spam di suatu webmail BigTech, dan karena itu bukan phishing jadi tidak ada opsi lain, layanan itu “dengan baik hati” malah membuka tautan berhenti berlangganan di browser lokal saya tanpa izin. Sulit membayangkan tingkat inkompetensi dan disfungsi organisasi seperti apa yang dibutuhkan untuk menulis, meninjau, menyetujui, dan meluncurkan fitur seperti itu dalam konteks yang sensitif terhadap keamanan dan privasi
  • Google memang memiliki Android, tetapi Google tidak peduli pada pengguna. Pelanggan mereka adalah penerbit iklan
    0-day juga bukan hal yang terlalu penting. Alternatifnya secara praktis cuma iPhone, dan Huawei pun hanya mungkin di wilayah tertentu, jadi hampir tidak ada alasan bagi mereka untuk peduli. Kita sangat membutuhkan OS ponsel baru beserta lapisan perangkat keras baru
  • Baru-baru ini saya mendengar presentasi “AI Security”, dan intinya kurang lebih “kita akan menelan mentah-mentah input yang masuk dan keluar lewat AI, itu memang masalah keamanan, tapi tidak banyak yang bisa dilakukan jadi ya tangani saja setelah kejadian”
    Presentasi itu juga mencakup pernyataan seperti “aktor ancaman bisa memengaruhi AI jika mereka memperbarui dokumen internal”, padahal kalau aktor ancaman memperbarui dokumen, berarti sistemnya sudah dibobol. Ini bukan sekadar setingkat “vandalisme Wikipedia”
  • Membuat pengguna membuka pesan bukanlah hambatan yang tinggi
    Sulit menerima bahwa dari sisi pengguna, mereka harus berhati-hati dalam memilih pesan mana yang boleh dibuka. Kita sudah mencoba melempar tanggung jawab ini ke pengguna lewat lampiran email, dan rasanya adil untuk mengatakan hasilnya adalah bencana. Lampiran berbahaya mungkin merupakan jalur paling penting untuk distribusi malware

• Kalimat “ini sangat cepat karena ini pertama kalinya bug driver Android ditambal dalam 90 hari sejak vendor pertama kali mengetahui kerentanannya setelah dilaporkan” membuat kesan saya terhadap Google membaik, tetapi pada saat yang sama ekosistem Android lainnya jadi agak menakutkan
  Saya jadi penasaran seperti apa waktu respons Apple

  • Vendor Android sudah lama terkenal buruk dalam hal pembaruan. Salah satu alasannya, kata orang, adalah karena perusahaan ponsel ingin saling membedakan diri dengan mem-fork UI Android bawaan agar bisa menawarkan fitur bermerek dan visi UI yang halusinatif
    Masalahnya, itu membuat pekerjaan migrasi jadi sangat besar saat pembaruan Android murni dirilis
  • Saya pernah melaporkan bug keamanan ke Apple. Itu beberapa tahun lalu, tetapi kalau tidak salah butuh sekitar 6 bulan sampai patch keluar
    Kami bolak-balik beberapa kali untuk membuat proof of concept yang lebih stabil, dan setelah saya mengirim proof of concept yang 100% dapat direproduksi, mungkin tinggal sekitar 2 bulan
  • Mengingat saat ini 42% perangkat Android belum ditambal [1], keputusan untuk memublikasikan riset ini dan membuat semuanya rentan terasa menarik
    [1] https://gs.statcounter.com/android-version-market-share
    [2] https://www.cybersecurity-insiders.com/survey-reveals-over-1...
  • Jika itu perangkat Android dari merek terkenal, Anda bisa berharap ada pembaruan keamanan OS karena vendor tingkat pertama bisa membangun dan mendorongnya sendiri
    Tetapi pembaruan keamanan driver dan firmware jauh lebih sulit dijamin. Pembaruan seperti itu sering kali harus datang dari pemasok di hulu, dan mereka bisa saja mau atau tidak mau memperbaiki masalah. Merek kecil sering menjual perangkat Android murah dan sama sekali tidak pernah memberi pembaruan

• Agak terkait, saya penasaran apakah persentase eksploit yang dipublikasikan belakangan ini memang benar-benar naik, atau hanya lebih sering muncul di berita karena AI sedang jadi sorotan sebagai alat keamanan ofensif maupun defensif
  Rasanya seperti setiap dua hari ada sesuatu yang baru dari Linux, Windows, mobile, atau alat umum yang dipakai semua orang

  • Jika membaca bagian 1 dengan saksama, kode yang bermasalah itu diperkenalkan karena fitur AI, dan eksploitnya ditemukan manusia
    https://projectzero.google/2026/01/pixel-0-click-part-1.html
    Jadi penggunaan AI menambah bug, dan manusialah yang harus memilahnya
  • Saya menganalisisnya sendiri akhir pekan lalu, dan pada 2024 ada kira-kira 100 CVE yang dipublikasikan per hari. Pada April jumlahnya mencapai sekitar 200 per hari
    Jika ditarik ke sebelum 2023, periode pelipatan ganda untuk CVE yang dipublikasikan adalah sekitar 4 sampai 4,5 tahun, tetapi sejak itu menjadi sekitar 2 tahun. Jelas meningkat tajam
  • Menurut orang-orang yang mengelola bug keamanan open source, jumlah laporan memang meningkat pesat. Awalnya sebagian besar hampir berupa laporan berkualitas rendah yang nyaris palsu, tetapi sekarang laporan yang benar-benar valid juga jauh lebih banyak
  • Ini murni dugaan dan saya bukan peneliti keamanan, tetapi tampaknya AI berperan sebagai akselerator yang sekaligus menambah permukaan serangan berkualitas rendah yang bisa dieksploitasi dan meningkatkan kecepatan kerja peneliti keamanan
    Artinya, kalau dipakai dengan baik hasilnya hebat, tetapi kalau dipakai buruk maka hasilnya benar-benar buruk
  • Dalam beberapa minggu terakhir saya melaporkan beberapa masalah yang cukup serius ke vendor alat yang banyak dipakai, dan jauh lebih sulit dari biasanya untuk mendapat pengakuan
    Saya dengar tim respons mereka kewalahan karena banjir laporan

• Saya ingin seseorang memeriksa apakah pemahaman saya benar. Saya memasukkan prompt persis berikut ke 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; }  
  

  Tanpa pencarian web pun model itu tepat mengidentifikasi masalahnya. Saya ingin mencoba secara lebih menyeluruh dengan memasukkan bukan hanya fungsi tertentu, tetapi keseluruhan potongan codebase ke prompt. Tampaknya ada potensi kemampuan untuk menangkap eksploit keamanan. Kalau begitu, saya jadi penasaran bagaimana ini bisa lolos sampai dirilis sejak awal. Saya tahu ini contoh mainan, tapi saya ingin belajar lebih banyak

  • Itu bukan pengujian yang adil. Walaupun prompt-nya tidak secara langsung menyuruh model mencari bug, prompt itu tetap mengarahkannya cukup kuat
    Ini pada dasarnya sama dengan sanggahan yang muncul di thread yang mengklaim model saat ini sebagus mythos
  • Sebagai anekdot, saya memasukkan fragnesia.c dan patch berikutnya yang ditujukan untuk memperbaiki masalah tersebut; memang tidak menemukan kerentanan baru yang sepenuhnya berbeda, tetapi tampaknya menemukan 2 cara baru untuk mengeksploitasi bug mendasar yang sama
    Kalau mengingat ini hasil percobaan orang bodoh seperti saya yang cuma punya langganan Claude, itu cukup mengesankan
  • Dari ini saja kita tidak bisa menilai apakah metode tersebut benar-benar berguna untuk menemukan kerentanan. Kita tidak tahu berapa banyak positif palsu yang akan keluar jika dijalankan ke seluruh kode
    Dengan kata lain, ini bisa jadi https://en.wikipedia.org/wiki/Base_rate_fallacy
  • Saya penasaran bagaimana Anda tahu bahwa model itu tidak melakukan pencarian web
  • Saya menempelkan kodenya ke claude Opus 4.7 tanpa akses internet dan hanya memintanya menjelaskan fungsi itu, lalu saat menjelaskan ia juga menunjukkan bug-nya. Saya tidak menyuruhnya mencari bug

    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:
       Jika kita memasuki era ketika bot bisa memindai PR semua proyek open source segera setelah muncul, siklus rilis 70 hari akan dengan cepat menjadi tidak memadai untuk mencegah eksploit digunakan secara luas

• Laporan bug yang luar biasa. Saya sama sekali bukan ahli kernel, dan hanya pernah membaca sedikit lebih dari 10 tahun lalu, tetapi saya tetap bisa mengikuti dan memahami apa yang terjadi
  Karena ini benar-benar bug serius dan tampaknya tidak perlu banyak kerja untuk menemukannya, saya jadi takut membayangkan risiko lain apa yang mungkin tersembunyi. Selain itu, akhir-akhir ini banyak isu keamanan ditemukan dengan AI, dan membaca laporan ini membuat saya memikirkan dua hal. Keahlian tetap sangat berharga, dan semakin niche bidangnya, semakin besar nilainya. Juga, masih banyak niche yang belum dikuasai AI

• Saya tidak tahu ke mana perginya jailbreak iPhone. Sudah cukup lama saya tidak melihat apa-apa, jadi sebenarnya apa yang terjadi? Saya penasaran apakah saya ketinggalan, atau memang tidak ada lagi yang memungkinkan
  Apa pun yang dilakukan Apple memang mengesankan, tetapi saya ingin tahu apakah dalam tren saat ini ini hanya soal waktu, atau memang ada perubahan nyata

  • Postur keamanan Apple jauh lebih baik daripada Android berkat Lockdown Mode, memory tagging, dan secure allocator
    Sebagiannya bisa dibaca di sini: https://security.apple.com/blog/memory-integrity-enforcement...
  • Sekarang ini eksploit yang bisa bertahan setelah reboot hampir mustahil. Dan eksploit yang memungkinkan jailbreak kini membutuhkan keseluruhan rantai eksploit, nilainya sangat tinggi, dan akan ditambal segera setelah dipublikasikan
    Jadi adegan jailbreak iPhone seperti dulu pada dasarnya sudah tidak mungkin lagi
  • Saya selalu kesal karena “jailbreak” tidak mendapat tingkat verifikasi yang sama seperti kerentanan perangkat lunak di platform lain

• Adakah bukti tentang dampak AI terhadap bisnis perusahaan seperti NSO? Saya penasaran apakah AI membuat mereka tidak berguna, atau justru membuat mereka makin sangat kuat

  • Saya tidak tahu detailnya, tetapi rasanya AI sedang mengubah permainan secara besar-besaran, dan banyak “modal” dalam bentuk 0-day mungkin telah lenyap
    Kalau begitu, itu kabar baik bagi semua orang kecuali NSO dan perusahaan sejenis

• Saya pernah mengalami masalah serupa. Solusinya tampak masuk akal, tetapi saya skeptis terhadap peningkatan performa yang diklaim

• Peningkatan V4L2 untuk mendukung decoding video perangkat keras sudah lama menunggu untuk digabungkan, dan sekarang tampaknya sudah masuk ke kernel mainline
  Mungkin orang-orang tidak ingin menunggu selama itu

• Agak mengejutkan bahwa bahkan Project Zero harus melaporkan bug ke Android lewat jalur formal dan harus berurusan dengan klasifikasi tingkat keparahan Android VRP
  Saya selalu mengira mereka bisa saja berjalan ke kantor Android dan meyakinkan orang secara langsung tentang pentingnya bug itu

  • Jika mereka merasa cara yang “normal” terlalu menyakitkan, mungkin langkah berikutnya yang dicoba Project Zero adalah memperbaiki proses itu sendiri
  • Itu bergantung pada asumsi bahwa Android akan mendengarkan Project Zero