Pixel 10 için 0-click exploit zinciri

 (projectzero.google)
1 puan yazan GN⁺ 2 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Pixel 10 zinciri, yama öncesinde Android genelinde bulunan Dolby 0-click açığını ilk aşama olarak kullanıyor ve yeni bir yerel yetki yükseltme yolu ekliyor
  • Pixel 9 zincirindeki BigWave sürücüsü Pixel 10'da bulunmadığı için taşınamadı; bunun yerine Tensor G5'in /dev/vpu arayüzü saldırı yüzeyi haline geldi
  • VPU sürücüsü, userspace'e MMIO register arayüzünü doğrudan açığa çıkarıyordu ve yalnızca 2 saatlik denetimde kritik bir mmap hatası bulundu
  • remap_pfn_range, register boyutunu değil yalnızca VMA boyutunu temel alarak eşleme yaptığı için çekirdek .text ve .data alanlarında okuma-yazma mümkün hale geldi
  • Açık, 24 Kasım 2025'te bildirildikten sonra 71 gün içinde yamandı; Android sürücü güvenliğinin hâlâ güçlendirilmesi gerekiyor

Pixel 10 0-click zincirinin yapısı

  • Google Pixel 9'da 0-click bağlamında Android root erişimine iki exploit ile ulaşan exploit zinciri temel alınarak, Pixel 10 için de benzer bir zincir oluşturuldu
  • Dolby 0-click açığı, 2026 Ocak yaması öncesine kadar Android genelinde mevcuttu ve Pixel 10 hedefli zincirde de ilk aşama olarak kullanıldı
  • Pixel 9'un yerel yetki yükseltme aşamasındaki BigWave sürücüsü, Pixel 10'a dahil edilmediği için doğrudan taşınamadı; Pixel 10'daki /dev/vpu sürücüsü yeni saldırı yüzeyi oldu

Dolby exploit güncellemesi

  • CVE-2025-54957 için mevcut exploit'i Pixel 10'a uyarlama işi büyük ölçüde Pixel 9 kütüphanesine göre olan offset'leri Pixel 10 kütüphanesindeki karşılık gelen offset'lerle güncellemekten ibaretti
  • Pixel 10, -fstack-protector yerine RET PAC kullandığı için __stack_chk_fail üzerine yazılamadı
  • Birden çok denemeden sonra, decoder başlatılırken bir kez çağrılan ve yeniden çağrılmayan başlatma kodu dap_cpdp_init üzerine yazma yöntemi kullanıldı
  • Güncellenmiş Dolby UDC exploit'i burada yayımlandı ve yalnızca 2025 Aralık SPL ve altı yamasız cihazlarda çalışıyor

BigWave'in kaldırılması ve VPU'nun eklenmesi

  • Pixel 10'da BigWave sürücüsü bulunmadığı için mevcut Pixel 9 zincirinin yerel yetki yükseltme aşaması taşınamadı
  • mediacodec SELinux bağlamından erişilebilen /dev/vpu sürücüsü yeni bir seçenek olarak öne çıktı; bu sürücü Tensor G5 çipindeki video çözme hızlandırması için Chips&Media Wave677DV silikonuyla etkileşim kurmakta kullanılıyor
  • Açık C dosyalarındaki yorumlara göre bu sürücü, BigWave sürücüsünü geliştiren ve bakımını yapan grupla aynı ekip tarafından geliştiriliyor ve sürdürülüyor
  • Jann Horn ile birlikte 2 saat boyunca VPU sürücüsü denetlendi ve bunun sonucunda son derece sıra dışı bir açık bulundu
  • Önceki Chips&Media çipi WAVE521C için upstream Linux sürücüsünden farklı olarak, Pixel'in WAVE677DV sürücüsü V4L2 ("Video for Linux API") ile entegre değil
  • Pixel sürücüsü, çipin donanım arayüzünü doğrudan userspace'e açıyor ve userspace'in çipin MMIO register arayüzünü eşlemesine izin veriyor
  • Sürücünün temel görevi cihaz bellek eşleme ayarlarını yapmak, güç yönetimini yürütmek ve userspace'in çip kesmelerini beklemesini desteklemek

Temel çekirdek açığı

  • İlgili hata, exploit edilmesi son derece basit bir zafiyetti
  • Sorunlu mmap handler'ı, VPU donanımının MMIO register alanını userland sanal adres alanına eşleyen koddu
  • remap_pfn_range çağrısı, register alanının boyutuyla sınırlandırılmadan yalnızca VMA boyutuna göre gerçekleştiriliyordu
  • Saldırgan, mmap sistem çağrısında register alanından daha büyük bir boyut belirleyerek VPU register alanının fiziksel adresinden başlayıp istediği kadar fiziksel belleği userland'e eşleyebiliyordu
  • Çekirdek imajının tamamı VPU register alanından daha yüksek fiziksel adreste bulunduğu için, bu hata çekirdeğin .text ve .data alanlarına erişmeyi ve bunları değiştirmeyi mümkün kılıyordu
  • Pixel'de çekirdek her zaman aynı fiziksel adreste konumlandığından, VPU bellek alanı ile çekirdek arasındaki offset her zaman bilinen bir değerdi
  • Yeterince büyük bir VMA uzunluğu belirtildiğinde, eşlenmiş fiziksel bellekte çekirdeği taramaya gerek kalmadan mmap tarafından döndürülen adrese göre çekirdeğin konumu tam olarak belirlenebiliyordu
  • Bu açıkla çekirdek üzerinde keyfi okuma-yazma elde etmek için 5 satır kod yeterli oldu ve tam exploit'in yazılması bir günden kısa sürdü
  • Rastgele bir çekirdek fonksiyonunun üzerine yazılarak çekirdek kod yürütmesi elde edilebilir veya istenen primitive oluşturulabilirdi

Yama süreci

  • Açık 24 Kasım 2025'te bildirildi ve Android VRP bu sorunu High şiddetinde değerlendirdi
  • Pixel 9 yetki yükseltmesinde kullanılan BigWave hatası güvenlik etkisi aynı olmasına rağmen başlangıçta Moderate olarak değerlendirilmişti; bu nedenle bu kez yapılan değerlendirme iyileşmiş bir yaklaşım olarak görülebilir
  • Açık, ilk bildirimden 71 gün sonra Şubat Pixel güvenlik bülteninde yamandı
  • Android sürücü hatalarının, vendor'a ilk bildirildikten sonra 90 gün içinde yamandığının değerlendirildiği ilk örnek olduğu belirtildi
  • Bu süreç, Android'in benzer türdeki hataları sınıflandırma ve yama konusundaki müdahalesinin anlamlı biçimde iyileştiğini gösterdi

Güvenlik açısından anlamı

  • VPU açığına verilen yanıt, Android'in sınıflandırma hattının iyileştiğini gösteriyor; ilk düzeltme, önceki BigWave sorununa kıyasla çok daha kısa sürede yapıldı
  • Kritik açıkları verimli biçimde yamalamaya dönük Android çabaları, çok sayıda Android cihazının korunmasına yardımcı oluyor
  • Aynı zamanda Android sürücülerinde daha kapsamlı ve güvenlik bilinci yüksek kod yazımına hâlâ ihtiyaç var
  • BigWave hatası bildirildikten sonra ilgili geliştiricilerin diğer sürücülerdeki bariz güvenlik sorunlarını gözden geçirmesi beklenirdi; ancak 5 ay sonra VPU sürücüsünde yüzeysel bir denetimle bile hemen görülebilen ciddi bir açık bulundu
  • Android ekosisteminin güvenliği için sürücü güvenliğinin güçlendirilmesi hâlâ önemli bir öncelik
  • Vendor'lar, açıkların son kullanıcıya ulaşmaması için yazılım geliştirme pratiklerini önceden iyileştirmeli; özellikle güvenlik açısından kritik ürünler, piyasaya çıktıkları anda makul ölçüde düşük açık seviyesine sahip olmalı
  • Yazılım ekipleri güvenlik, kod denetimi ve açık yamalama konusunda proaktif bir yaklaşım benimsemeli

İlgili okumalar

1 yorum

 
GN⁺ 2 시간 전
Hacker News yorumları

  • Pixel 9 hata/istismar bağlantısını takip edince, AI özellikleri yüzünden mesajları kullanıcı açmadan önce medyanın decode edilmesi gerektiği ve bunun da 0-click saldırı yüzeyini büyüttüğü söyleniyordu
    Bu dersin zaten çıkarılmış olması gerekirdi diye düşünüyorum. Ben istemediysem, SMS'lerimi okuyup bir şeyler yapmamalı

    • Çıkarmamız gereken dersin tam olarak ne olduğundan emin değilim
      Kullanıcılar zengin mesajlaşma özelliklerine sahip telefonları seçiyor. iPhone'da iMessage, daha sonra da Android'de RCS yetişene kadar bunun büyük bir satış noktası olduğu biliniyordu
    • Bu tek başına yeterli değil. Kullanıcı mesajla etkileşime geçene kadar görselleri parse etmeyen bir e-posta istemcisini düşünün; tıklayıp şüpheli olduğunu fark ettiğiniz anda, karmaşık ve hataya açık mekanizma zaten çalışmış oluyor
      Şahsen gördüğüm en saçma şeylerden biri, bir BigTech webmail hizmetinde neredeyse kesin olarak kötü amaçlı ek içeren son derece şüpheli bir mesajı spam olarak işaretlediğimde, phishing olmadığı için başka seçenek de yokken, sistemin “iyilik yapıp” yerel tarayıcımda abonelikten çıkma bağlantısını izinsiz açmasıydı. Güvenlik ve gizliliğin hassas olduğu bir bağlamda böyle bir özelliği yazmak, incelemek, onaylamak ve dağıtmak için ne düzeyde bir beceriksizlik ve kurumsal işlev bozukluğu gerektiğini hayal etmek zor
    • Google Android'e sahip ama Google'ın kullanıcıyı umursadığı yok. Onların müşterisi reklamverenler
      0-day de pek önemli değil. Gerçekçi alternatif neredeyse sadece iPhone ve Huawei de bölgeye göre ancak mümkün, dolayısıyla pek umursamaları için neden yok. Acilen yeni telefon işletim sistemlerine ve donanım katmanlarına ihtiyacımız var
    • Yakın zamanda bir “AI Security” sunumu dinledim; özü kabaca şuydu: “AI'a giren ve çıkan verileri eleştirel süzgeçten geçirmeden yutacağız, bu bir güvenlik sorunu ama yapacak bir şey yok, siz de sonradan uğraşın”
      İçinde “tehdit aktörü dahili belgeleri güncellerse bununla AI'ı etkileyebilir” gibi bir ifade de vardı ama tehdit aktörü belge güncelliyorsa zaten ihlal gerçekleşmiştir. Burada kastedilen şey “Wikipedia vandallığı” seviyesinde değil
    • Kullanıcıyı mesajı açmaya ikna etmek çok yüksek bir eşik değil
      Kullanıcının hangi mesajları açacağı konusunda aşırı dikkatli olmak zorunda kalması kabul edilebilir değil. E-posta eklerinde sorumluluğu kullanıcıya yüklemeyi denedik ve bence sonuç tam bir felaketti. Kötü amaçlı ekler muhtemelen zararlı yazılım dağıtımının en önemli yollarından biri

  • “Android sürücü hatasını bildirdikten sonra, satıcının açığı ilk fark ettiği andan itibaren 90 gün içinde yama çıkması ilk kez oluyor; bu yüzden özellikle hızlı” ifadesi Google hakkındaki izlenimimi iyileştiriyor ama aynı zamanda Android ekosisteminin geri kalanı biraz korkutucu geliyor
    Apple'ın yanıt süresi nasıldır acaba

    • Android satıcıları güncellemeler konusunda uzun zamandır kötü şöhretli. Bunun nedenlerinden birinin, telefon şirketlerinin birbirlerinden ayrışmak için temel Android UI'ını fork etmesi, markaya özel özellikler ve halüsinatif UI vizyonları eklemeye çalışması olduğu söylenirdi
      Ama bu durumda stok Android güncellemesi geldiğinde geçiş işi korkunç derecede büyüyor
    • Bir zamanlar Apple'a bir güvenlik açığı bildirmiştim. Birkaç yıl önceydi ama yamaya kadar yaklaşık 6 ay sürdüğünü hatırlıyorum
      Daha kararlı bir PoC üretmek için birkaç kez gidip geldik ve %100 yeniden üretilebilen PoC'yi gönderdikten sonra muhtemelen 2 ay kadar sürmüştü
    • Şu anda Android cihazların %42'sinin yamalanmamış olduğu düşünülürse [1], araştırmayı yayımlayıp hepsini savunmasız bırakma kararı ilginç
      [1] https://gs.statcounter.com/android-version-market-share
      [2] https://www.cybersecurity-insiders.com/survey-reveals-over-1...
    • Tanınmış bir markanın Android cihazıysa, OS güvenlik güncellemeleri beklenebilir. Çünkü birincil satıcı bunu doğrudan build edip push edebilir
      Ama sürücü ve firmware güvenlik güncellemeleri için aynı şeyi söylemek zor. Bu tür güncellemelerin çoğu zaman yukarı akış tedarikçiden gelmesi gerekir ve onların sorunu düzeltmek gibi bir niyeti olabilir de olmayabilir de. Küçük markalar ise genelde ucuz Android cihazlar satar ve hiç güncelleme vermez

  • Biraz bağlantılı olarak, son dönemde kamuya açıklanan istismarların oranı gerçekten arttı mı, yoksa AI saldırı ve savunma güvenlik araçlarında gündeme geldiği için sadece haberlerde daha sık mı görüyoruz, merak ediyorum
    Sanki iki günde bir Linux, Windows, mobil ya da herkesin kullandığı yaygın araçlardan birinde yeni bir şey çıkıyor

      1. bölümü satır aralarını da okuyarak incelerseniz, sorunlu kodun AI özelliği yüzünden eklendiğini ve istismarın bir insan tarafından bulunduğunu görüyorsunuz
        https://projectzero.google/2026/01/pixel-0-click-part-1.html
        Yani AI kullanımı hataları artırıyor, insan da bunları ayıklamak zorunda kalıyor
    • Geçen hafta sonu bunu bizzat analiz ettim; 2024'te açıklanan CVE sayısı günde yaklaşık 100'dü. Nisan ayında bu rakam günlük yaklaşık 200 seviyesine ulaştı
      2023 öncesine gidersek, yayımlanan CVE'lerde ikiye katlanma döngüsü yaklaşık 4 ila 4,5 yıldı; ondan sonra yaklaşık 2 yıla düştü. Kesinlikle ciddi biçimde hızlandı
    • Açık kaynak güvenlik açıklarını yöneten kişilere göre bildirimlerde büyük bir artış var. Başta bunların çoğu neredeyse sahte denecek kadar düşük kaliteli bildirimlerdi, ama artık gerçekten geçerli bildirimler de çok daha fazla geliyormuş
    • Bu tamamen tahmin ve ben bir güvenlik araştırmacısı değilim ama AI'ın hem düşük kaliteli istismar edilebilir saldırı yüzeyini artıran, hem de güvenlik araştırmacılarının çalışma hızını yükselten bir hızlandırıcı gibi davrandığını düşünüyorum
      Yani iyi kullanılırsa harika, kötü kullanılırsa gerçekten kötü
    • Son birkaç haftada yaygın kullanılan araçların satıcılarına epey ciddi birkaç sorun bildirdim ve bunların kabul edilmesi her zamankinden daha zor oldu
      Yanıt ekiplerinin bildirim seli yüzünden aşırı yüklendiğini duydum

  • Yanılıyor muyum diye biri keşke kontrol etse. Aşağıdaki tam prompt'u gpt 5.5 xhigh'e verdim

    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; }

    Web araması yapmadan da sorunu tam isabetle yakaladı. Sadece tek bir fonksiyon yerine tüm kod tabanı parçalarını prompt'a vererek daha kapsamlı denemek istiyorum. Güvenlik istismarlarını yakalama potansiyeli var gibi görünüyor. Öyleyse bunun en başta nasıl release edildiğini merak ediyorum. Oyuncak bir örnek olduğunu biliyorum ama daha fazlasını öğrenmek istiyorum

    • Bu adil bir test değil. Prompt doğrudan hata bul demese de modeli oldukça güçlü biçimde yönlendiriyor
      Bu, mevcut modellerin mythos kadar iyi olduğunu iddia eden başlıktaki itirazla temelde aynı
    • Anekdot olarak, fragnesia.c'yi ve sonra sorunu düzeltmeye yönelik yamayı verdim; tamamen yeni bir açık bulmadı ama aynı temel hatayı istismar eden iki yeni yöntem bulmuş gibi görünüyordu
      Bunu sadece Claude aboneliği olan benim gibi bir aptalın denemiş olması düşünülürse oldukça etkileyici
    • Sadece buna bakarak bunun açık bulmada gerçekten işe yarar bir yöntem olup olmadığını söyleyemeyiz. Çünkü tüm koda uygulandığında ne kadar false positive üreteceğini bilmiyoruz
      Başka bir deyişle bu https://en.wikipedia.org/wiki/Base_rate_fallacy olabilir
    • Web araması yapmadığını nasıl bildiğinizi merak ediyorum
    • İnternet erişimi olmayan claude Opus 4.7'ye kodu yapıştırıp sadece fonksiyonun ne yaptığını açıklamasını istedim; açıklarken hatayı da işaret etti. Hata bulmasını söylememiştim

      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:
        Botların tüm açık kaynak projelerin PR'larını çıkar çıkmaz tarayabildiği bir çağdaysak, 70 günlük release döngüsü istismarların yaygın kullanımını engellemek için çok yakında yetersiz kalacak

  • Harika bir hata raporu. Hiç kernel uzmanı değilim; 10 yıldan uzun süre önce biraz okumuştum, o kadar. Buna rağmen takip edip neler olduğunu anlayabildim
    Bunun gerçekten ciddi bir hata olması ve bulunmasının da o kadar çok emek gerektirmemiş gibi görünmesi, başka ne tür risklerin gizleniyor olabileceği konusunda beni ürkütüyor. Son dönemde birçok güvenlik sorunu AI ile bulunuyor ve bu rapor bana iki şey düşündürdü. Uzmanlık hâlâ muazzam derecede değerli ve ne kadar nişse o kadar değerli. Ayrıca AI'ın henüz domine etmediği çok sayıda niş alan var

  • iPhone jailbreak'leri nereye gitti bilmiyorum. Oldukça uzun süredir hiçbir şey görmedim; ne oluyor acaba? Bir şeyi kaçırıyor muyum, yoksa gerçekten yapılabilir bir şey mi kalmadı, merak ediyorum
    Apple ne yapıyorsa etkileyici ama mevcut gidişat bunun sadece zaman meselesi mi olduğunu yoksa gerçekten bir şeylerin değişip değişmediğini bilmek isterim

    • Apple'ın güvenlik duruşu Lockdown Mode, memory tagging ve secure allocator sayesinde Android'den belirgin biçimde daha iyi
      Bunun bir kısmını burada okuyabilirsiniz: https://security.apple.com/blog/memory-integrity-enforcement...
    • Artık yeniden başlatmadan sonra da kalıcı olan istismarlar neredeyse imkânsız. Ayrıca jailbreak sağlayan istismarlar artık tüm istismar zincirini gerektiriyor, ciddi değere sahip oluyor ve yayımlanır yayımlanmaz yamalanıyor
      Bu yüzden eski iPhone jailbreak sahnesi artık mümkün değil
    • “Jailbreak” kavramının diğer platformlardaki yazılım açıklarıyla aynı düzeyde incelemeye tabi tutulmaması hep sinir bozucu gelmiştir

  • AI'ın NSO gibi şirketlerin işine ne etkisi olduğuna dair bir kanıt var mı? Onları gereksiz mi kılıyor, yoksa tam tersine aşırı güçlendiriyor mu, merak ediyorum

    • Ayrıntıları bilmiyorum ama AI'ın oyunu ciddi biçimde değiştirdiğini ve 0-day biçimindeki “sermayenin” büyük kısmını ortadan kaldırmış olabileceğini düşünüyorum
      Eğer öyleyse, NSO ve benzerleri dışındaki herkes için iyi haber

  • Benzer bir sorun yaşamıştım. Çözüm makul görünüyor ama iddia edilen performans iyileştirmesi konusunda şüpheliyim

  • Donanımsal video decode desteği için V4L2 iyileştirmeleri uzun süre merge edilmeyi bekledi ve şimdi ana kernel ağacına girmiş gibi görünüyor
    Muhtemelen insanlar o kadar uzun beklemek istemedi

  • Project Zero'nun da Android'e hataları resmî kanaldan bildirmek ve Android VRP önem sınıflandırmasıyla uğraşmak zorunda olması şaşırtıcı
    Ben hep, Android ofisine yürüyüp giderek yüz yüze hata önemini anlatabileceklerini düşünmüştüm

    • Eğer “normal” yöntem fazla acı vericiyse, Project Zero muhtemelen bir sonraki adımda o yöntemin kendisini düzeltmeye çalışmıştır
    • Bu, Android'in Project Zero'yu dinlediği varsayımına dayanıyor