Pixel 10 के लिए 0-click exploit chain

 (projectzero.google)
1 पॉइंट द्वारा GN⁺ 2 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Pixel 10 chain ने पैच से पहले पूरे Android में मौजूद Dolby 0-click vulnerability को पहले चरण के रूप में इस्तेमाल किया और एक नया local privilege escalation path जोड़ा
  • Pixel 9 chain का BigWave driver Pixel 10 में नहीं था, इसलिए उसे port नहीं किया जा सका; इसके बजाय Tensor G5 का /dev/vpu attack surface बना
  • VPU driver ने userspace को MMIO register interface सीधे expose किया, और सिर्फ 2 घंटे की audit में एक गंभीर mmap bug मिल गया
  • remap_pfn_range ने register size के बजाय सिर्फ VMA size के आधार पर mapping की, जिससे kernel .text और .data को read/write करना संभव हो गया
  • vulnerability को 24 नवंबर 2025 को report किया गया और 71 दिनों में patch कर दिया गया, लेकिन Android driver security hardening की अब भी ज़रूरत है

Pixel 10 0-click chain की संरचना

  • Google Pixel 9 में 0-click context से Android root तक पहुँचाने वाले दो exploits की exploit chain के आधार पर, Pixel 10 के लिए भी एक समान chain बनाई गई
  • Dolby 0-click vulnerability जनवरी 2026 patch से पहले पूरे Android में मौजूद थी, और Pixel 10 target chain में भी इसे पहले चरण के रूप में इस्तेमाल किया गया
  • Pixel 9 का local privilege escalation चरण, यानी BigWave driver, Pixel 10 में शामिल नहीं था, इसलिए उसे वैसे का वैसा port नहीं किया जा सका; Pixel 10 का /dev/vpu driver नया attack surface बना

Dolby exploit अपडेट

  • CVE-2025-54957 के लिए मौजूदा exploit को Pixel 10 के अनुरूप ढालने का काम ज़्यादातर Pixel 9 library-आधारित offsets को Pixel 10 library के corresponding offsets से अपडेट करने तक सीमित था
  • Pixel 10 -fstack-protector की जगह RET PAC का उपयोग करता है, इसलिए __stack_chk_fail को overwrite नहीं किया जा सकता था
  • कई प्रयासों के बाद, decoder initialization के समय एक बार call होने वाले और फिर दोबारा call न होने वाले initialization code dap_cpdp_init को overwrite करने का तरीका अपनाया गया
  • अपडेट किया गया Dolby UDC exploit यहाँ प्रकाशित है, और यह केवल दिसंबर 2025 SPL या उससे पुराने unpatched devices पर काम करता है

BigWave हटना और VPU का जुड़ना

  • Pixel 10 में BigWave driver नहीं था, इसलिए पुरानी Pixel 9 chain के local privilege escalation चरण को port नहीं किया जा सका
  • mediacodec SELinux context से access किया जा सकने वाला /dev/vpu driver नया दिखाई दिया; यह Tensor G5 chip के video decoding acceleration के लिए Chips&Media Wave677DV silicon के साथ interaction में इस्तेमाल होता है
  • सार्वजनिक C file की टिप्पणियों से पता चलता है कि यह driver BigWave driver बनाने वाले developers के उसी group द्वारा विकसित और maintained है
  • Jann Horn के साथ 2 घंटे तक VPU driver की audit करने पर एक बेहद असामान्य vulnerability मिली
  • पुराने Chips&Media chip WAVE521C के upstream Linux driver के विपरीत, Pixel का WAVE677DV driver V4L2 (“Video for Linux API”) के साथ integrated नहीं है
  • Pixel driver chip के hardware interface को सीधे userspace के सामने expose करता है, और userspace को chip के MMIO register interface को map करने देता है
  • driver की मुख्य भूमिका device memory mapping setup, power management, और userspace को chip interrupts का इंतज़ार करने में सहायता देना है

मुख्य kernel vulnerability

  • यह bug ऐसी vulnerability थी जिसका exploit बेहद सरल था
  • संबंधित mmap handler वह code है जो VPU hardware के MMIO register region को userland virtual address space में map करता है
  • remap_pfn_range call को register region के size तक सीमित नहीं किया गया, बल्कि यह सिर्फ VMA size के आधार पर किया गया
  • attacker mmap system call में register region से बड़ा size देकर, VPU register region के physical address से शुरू होकर जितनी चाहे physical memory userland में map कर सकता है
  • क्योंकि पूरा kernel image VPU register region से ऊँचे physical addresses पर स्थित होता है, इस bug के जरिए kernel के .text और .data regions तक पहुँचकर उन्हें modify किया जा सकता है
  • Pixel में kernel हमेशा एक ही physical address पर स्थित होता है, इसलिए VPU memory region और kernel के बीच offset हमेशा ज्ञात मान होता है
  • पर्याप्त बड़ा VMA length देने पर mapped physical memory में kernel को scan किए बिना भी, mmap द्वारा लौटाए गए address के आधार पर kernel की सटीक position पता चल सकती है
  • इस vulnerability से kernel arbitrary read/write हासिल करने के लिए सिर्फ 5 lines of code की ज़रूरत थी, और पूरा exploit लिखने में एक दिन से कम समय लगा
  • किसी भी kernel function को overwrite करके kernel code execution हासिल किया जा सकता है या मनचाहे primitives बनाए जा सकते हैं

patch प्रक्रिया

  • vulnerability को 24 नवंबर 2025 को report किया गया था, और Android VRP ने इसे High severity के रूप में आंका
  • Pixel 9 privilege escalation में इस्तेमाल किया गया BigWave bug security impact के लिहाज़ से समान था, लेकिन उसे शुरुआत में Moderate आंका गया था; इसलिए इस बार की rating को बेहतर handling माना जा सकता है
  • vulnerability को पहली report के 71 दिन बाद फरवरी Pixel security bulletin में patch किया गया
  • Android driver bugs में यह पहली बार माना गया कि vendor को पहली report के 90 दिनों के भीतर patch जारी कराया गया
  • इस handling process से पता चलता है कि Android की प्रतिक्रिया, खासकर समान प्रकार के bugs को classify और patch करने में, अर्थपूर्ण रूप से बेहतर हुई है

सुरक्षा महत्व

  • VPU vulnerability पर की गई प्रतिक्रिया दिखाती है कि Android का classification pipeline बेहतर हुआ है, और शुरुआती fix पहले के BigWave issue की तुलना में कहीं कम समय में आ गया
  • गंभीर vulnerabilities को कुशलता से patch करने की Android की कोशिशें कई Android devices की सुरक्षा में मदद करती हैं
  • साथ ही, Android drivers में अभी भी अधिक गहन और security-conscious code की निरंतर आवश्यकता है
  • BigWave bug report के बाद उम्मीद थी कि संबंधित developers दूसरे drivers में स्पष्ट security issues की जाँच करेंगे, लेकिन 5 महीने बाद VPU driver में एक ऐसी गंभीर vulnerability मिली जो सतही audit में ही तुरंत सामने आ गई
  • Android ecosystem की सुरक्षा के लिए driver security hardening अब भी एक अहम प्राथमिकता है
  • vendors को अपने software development practices पहले से बेहतर बनाने चाहिए ताकि vulnerabilities end users तक पहुँचने ही न पाएँ, खासकर security-critical products में release के समय से ही reasonably low vulnerability state होना चाहिए
  • software teams को security, code audit, और vulnerability patching के लिए proactive approach अपनानी चाहिए

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2 시간 전
Hacker News की राय

  • Pixel 9 bug/exploit लिंक को फॉलो करके देखा तो उसमें कहा गया था कि AI फीचर्स की वजह से यूज़र के संदेश खोलने से पहले ही media decode करना पड़ता है, इसलिए 0-click attack surface बढ़ जाता है
    लगता है यह सबक तो हमें पहले ही मिल जाना चाहिए था। यानी जो मैंने माँगा ही नहीं, उसके लिए SMS पढ़कर कुछ प्रोसेस मत करो

    • मुझे ठीक-ठीक समझ नहीं आता कि वह सबक क्या है जो हमें सीखना चाहिए था
      यूज़र ऐसे फ़ोन चुनते हैं जिनमें rich messaging features हों। iPhone में iMessage, और बाद में Android में RCS के बराबरी पर आने से पहले तक, यह एक बड़ा selling point था
    • सिर्फ़ इतना काफ़ी नहीं है। अगर आप ऐसे email client के बारे में सोचें जो यूज़र के संदेश के साथ interact करने से पहले images parse न करे, तब भी जिस क्षण आप क्लिक करके समझते हैं कि कुछ संदिग्ध है, तब तक complex और bug-prone machinery पहले ही चल चुकी होती है
      मेरे लिए सबसे बेतुकी बात तब हुई जब मैंने एक BigTech webmail में एक बहुत संदिग्ध संदेश को spam मार्क किया, जिसमें लगभग तय था कि malicious attachment है; वह phishing नहीं था इसलिए कोई दूसरा विकल्प नहीं था, और उसने “मददगार” बनते हुए मेरे local browser में unsubscribe link बिना अनुमति के खोल दिया। security और privacy-संवेदनशील संदर्भ में ऐसी feature को लिखने, review करने, approve करने और deploy करने के लिए कितनी अयोग्यता और organizational dysfunction चाहिए होगी, यह कल्पना करना मुश्किल है
    • Google, Android का मालिक है, लेकिन Google को यूज़र्स की परवाह नहीं है। उसके ग्राहक ad publishers हैं
      0-day भी ज़्यादा मायने नहीं रखता। विकल्प लगभग सिर्फ़ iPhone ही है, और Huawei भी क्षेत्र के हिसाब से ही संभव है, इसलिए उनके पास चिंता न करने की वजह है। हमें नए phone OS और hardware layers की सख़्त ज़रूरत है
    • मैंने हाल में “AI Security” पर एक प्रस्तुति सुनी, और उसका सार क़रीब-क़रीब यह था: “हम AI के अंदर और बाहर जाने वाले inputs को बिना आलोचनात्मक जांच के निगल लेंगे, यह security problem है, पर कुछ कर नहीं सकते, तो बाद में cleanup कर लो”
      इसमें यह भी कहा गया कि “अगर threat actor internal documents अपडेट कर दे तो वह AI को प्रभावित कर सकता है”, लेकिन अगर threat actor documents अपडेट कर रहा है, तो compromise पहले ही हो चुका है। यहाँ बात “Wikipedia vandal” स्तर की नहीं है
    • यूज़र से message खुलवा लेना कोई बहुत बड़ी बाधा नहीं है
      यूज़र के नज़रिए से यह मानना कठिन है कि उन्हें किस message को खोलना है, इसमें इतनी सावधानी रखनी पड़े। हमने email attachments के मामले में ज़िम्मेदारी यूज़र पर डालकर देख लिया, और यह कहना उचित होगा कि उसका नतीजा विनाशकारी रहा। malicious attachments शायद malware delivery का सबसे महत्वपूर्ण रास्ता हैं

  • “Android driver bug की रिपोर्ट के बाद vendor ने vulnerability को पहली बार स्वीकार करने के 90 दिनों के भीतर patch किया; यह पहली बार है, इसलिए खास तौर पर तेज़ है” यह पंक्ति Google के बारे में अच्छा असर छोड़ती है, लेकिन साथ ही बाकी Android ecosystem थोड़ा डरावना लगता है
    Apple का response time कैसा होता होगा, यह जानने की जिज्ञासा है

    • Android vendors लंबे समय से updates को लेकर बदनाम रहे हैं। एक वजह यह बताई जाती है कि phone कंपनियाँ एक-दूसरे से अलग दिखने के लिए base Android UI को fork कर देती हैं, ताकि brand-specific features और भ्रमित कर देने वाली UI visions दे सकें
      लेकिन फिर जब stock Android update आता है, तो migration work बहुत बड़ा हो जाता है
    • मैंने पहले Apple को एक security bug रिपोर्ट किया था। यह कुछ साल पुरानी बात है, लेकिन याद है कि patch आने में लगभग 6 महीने लगे थे
      ज़्यादा stable proof of concept बनाने के लिए कुछ बार बातचीत हुई, और 100% reproducible proof of concept जमा करने के बाद शायद लगभग 2 महीने लगे
    • जब मौजूदा Android devices में से 42% unpatched हैं [1], तो research publish करके सबको vulnerable बना देने का फ़ैसला दिलचस्प लगता है
      [1] https://gs.statcounter.com/android-version-market-share
      [2] https://www.cybersecurity-insiders.com/survey-reveals-over-1...
    • अगर यह किसी प्रसिद्ध brand का Android device है, तो OS security updates की उम्मीद की जा सकती है, क्योंकि primary vendor खुद build करके push कर सकता है
      लेकिन driver और firmware security updates की गारंटी देना मुश्किल है। ऐसे updates अक्सर upstream suppliers से आने पड़ते हैं, और वे समस्या ठीक करना चाहते भी हों या नहीं भी। छोटे brand अक्सर सस्ते Android devices बेचते हैं और updates देते ही नहीं

  • थोड़ा संबंधित सवाल: क्या हाल में public exploits की दर वाकई बढ़ी है, या फिर AI attack/defense security tools पर ध्यान होने की वजह से वे बस ख़बरों में ज़्यादा दिख रहे हैं?
    ऐसा लगता है कि हर दूसरे दिन Linux, Windows, mobile, और आम तौर पर इस्तेमाल होने वाले tools में कुछ नया निकल रहा है

    • अगर भाग 1 को ध्यान से पढ़ें, तो समस्या वाला code AI feature की वजह से जोड़ा गया था और exploit इंसान ने खोजा था
      https://projectzero.google/2026/01/pixel-0-click-part-1.html
      तो AI का उपयोग bugs बढ़ा रहा है, और इंसानों को उन्हें चुन-छाँटकर ढूँढ़ना पड़ रहा है
    • मैंने पिछले weekend खुद data देखा था; 2024 में रोज़ लगभग 100 public CVE थे। अप्रैल में यह रोज़ लगभग 200 तक पहुँच गया
      2023 से पहले public CVE के doubling time लगभग 4 से 4.5 साल थे, लेकिन उसके बाद से यह लगभग 2 साल रह गया है। बढ़ोतरी साफ़ तौर पर तेज़ हुई है
    • open source security bugs संभालने वाले लोगों के मुताबिक reports काफ़ी बढ़ गई हैं। शुरुआत में ज़्यादातर लगभग नकली जैसी low-quality reports थीं, लेकिन अब सचमुच valid reports भी कहीं ज़्यादा आ रही हैं
    • यह सिर्फ़ अंदाज़ा है, और मैं security researcher नहीं हूँ, लेकिन लगता है AI एक accelerator की तरह काम कर रहा है: एक तरफ़ यह exploitable low-quality attack surface बढ़ाता है, दूसरी तरफ़ security researchers की रफ़्तार भी बढ़ाता है
      यानी सही इस्तेमाल करो तो शानदार, ग़लत इस्तेमाल करो तो बहुत बुरा
    • मैंने हाल के हफ्तों में widely used tools के vendors को कुछ काफ़ी गंभीर issues रिपोर्ट किए, लेकिन acknowledgment मिलना सामान्य से ज़्यादा कठिन था
      सुना है response teams report flood की वजह से overload में हैं

  • कोई मेरी समझ की पुष्टि कर दे तो अच्छा होगा। मैंने नीचे वाला exact prompt 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; }

    इसने web search के बिना भी समस्या ठीक से पकड़ ली। मैं इसे सिर्फ़ एक function नहीं बल्कि पूरे codebase के chunk देकर और व्यापक ढंग से आज़माना चाहता हूँ। security exploits पकड़ने की संभावित क्षमता इसमें लगती है। फिर सवाल यह है कि यह पहले release कैसे हो गया। पता है कि यह toy example है, लेकिन और सीखना चाहता हूँ

    • यह fair test नहीं है। prompt सीधे bug ढूँढ़ने को नहीं कहता, लेकिन model को काफ़ी मज़बूती से उसी दिशा में ले जाता है
      मूल रूप से वही counterpoint है जो उस thread में आया था जहाँ दावा किया गया था कि मौजूदा models mythos जितने अच्छे हैं
    • एक anecdote के तौर पर, मैंने fragnesia.c और बाद में issue ठीक करने वाले patch को इसमें डाला; इसने बिल्कुल नई vulnerability तो नहीं खोजी, लेकिन उसी root bug का फायदा उठाने के 2 नए तरीके शायद ढूँढ़ लिए
      यह सोचकर काफ़ी प्रभावशाली लगता है कि यह काम मेरे जैसे एक बेवकूफ़ ने किया, जिसके पास सिर्फ़ Claude subscription है
    • सिर्फ़ इससे यह तय नहीं किया जा सकता कि vulnerability hunting के लिए यह व्यावहारिक रूप से उपयोगी है या नहीं। वजह यह है कि जब इसे पूरे code पर चलाएँगे तो false positives कितने होंगे, पता नहीं
      दूसरे शब्दों में, यह https://en.wikipedia.org/wiki/Base_rate_fallacy हो सकता है
    • यह कैसे पता कि उसने web search नहीं किया?
    • मैंने internet access के बिना Claude Opus 4.7 में code paste करके सिर्फ़ यह समझाने को कहा कि function क्या करता है, और उसने समझाते-समझाते bug भी बता दिया। मैंने 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:
        अगर ऐसा समय आ गया कि bots सभी open source projects के PR आते ही scan कर सकें, तो 70-day release cycle जल्द ही widespread exploit use को रोकने के लिए नाकाफ़ी पड़ जाएगी

  • यह एक शानदार bug report है। मैं kernel expert बिल्कुल नहीं हूँ, 10 साल से भी ज़्यादा पहले थोड़ा-बहुत पढ़ा था, फिर भी follow करते हुए समझ पा रहा था कि क्या हो रहा है
    यह देखकर डर लगता है कि bug इतना गंभीर था और इसे ढूँढ़ने में बहुत ज़्यादा मेहनत भी नहीं लगती दिखी। पता नहीं और क्या-क्या जोखिम छिपे होंगे। और हाल में इतने security issues AI से खोजे जा रहे हैं कि यह report मुझे दो बातें सोचने पर मजबूर करती है। expertise अब भी बेहद मूल्यवान है, और niche जितनी गहरी हो, उतनी ज़्यादा मूल्यवान है। और अभी भी बहुत-सी niches बची हैं जहाँ AI का दबदबा नहीं है

  • iPhone jailbreak का क्या हुआ, समझ नहीं आता। काफ़ी लंबे समय से कुछ दिखा नहीं; आखिर चल क्या रहा है? समझ नहीं आता कि मैंने मिस कर दिया या अब सच में कुछ संभव ही नहीं है
    Apple जो भी कर रहा है, वह प्रभावशाली है, लेकिन मौजूदा रुझान को देखते हुए जानना चाहता हूँ कि यह सिर्फ़ समय की बात है या सच में कुछ बदल गया है

    • Apple की security posture, Lockdown Mode, memory tagging, और secure allocators की वजह से Android से काफ़ी बेहतर है
      इसका कुछ हिस्सा यहाँ पढ़ सकते हैं: https://security.apple.com/blog/memory-integrity-enforcement...
    • आजकल reboot के बाद भी टिके रहने वाले exploits लगभग असंभव हैं। और jailbreak संभव बनाने वाले exploits को अब पूरे exploit chain की ज़रूरत होती है, उनकी क़ीमत काफ़ी ऊँची होती है, और public होते ही patch कर दिए जाते हैं
      इसलिए पुराने iPhone jailbreak scene जैसी चीज़ अब संभव नहीं रही
    • मुझे हमेशा यह खलता रहा है कि “jailbreak” को दूसरे platforms की software vulnerabilities जितनी scrutiny नहीं मिलती

  • क्या कोई सबूत है कि AI ने NSO जैसी कंपनियों के बिज़नेस को कैसे प्रभावित किया है? समझ नहीं आता कि यह उन्हें बेकार बना रहा है या उल्टा supercharge कर रहा है

    • मुझे details नहीं पता, लेकिन लगता है AI खेल को काफ़ी बदल रहा है, और 0-day के रूप में मौजूद बहुत-सा “capital” शायद मिट गया होगा
      अगर ऐसा है, तो NSO और ऐसी कंपनियों को छोड़कर बाकी सबके लिए यह अच्छी ख़बर है

  • मुझे भी ऐसा ही issue झेलना पड़ा है। समाधान तर्कसंगत लगता है, लेकिन दावा किए गए performance improvement को लेकर मैं सशंकित हूँ

  • hardware video decoding को support करने के लिए V4L2 improvements काफ़ी समय से merge होने का इंतज़ार कर रहे थे, और अब लगता है कि वे mainline kernel में पहुँच गए हैं
    शायद लोग इतना लंबा इंतज़ार नहीं करना चाहते थे

  • यह थोड़ा surprising है कि Project Zero भी Android को bugs औपचारिक channel से रिपोर्ट करता है और Android VRP severity classification से जूझना पड़ता है
    मैं हमेशा सोचता था कि वे बस Android office तक चलकर जा सकते होंगे और सामने बैठकर bug की गंभीरता समझा सकते होंगे

    • अगर “normal” तरीका इतना दर्दनाक लगा होगा, तो शायद Project Zero ने अगला प्रयास उसी प्रक्रिया को ठीक कराने के लिए किया होगा
    • यह इस धारणा पर टिका है कि Android, Project Zero की बात सुनता भी है