GrapheneOS ने उस Android VPN लीक को ठीक किया जिसे Google ने patch करने से मना कर दिया था

 (cyberinsider.com)
1 पॉइंट द्वारा GN⁺ 6 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • GrapheneOS ने नए अपडेट में उस VPN bypass vulnerability को ठीक किया है, जिसमें Android में “Always-On VPN” और “Block connections without VPN” चालू होने पर भी असली IP address लीक हो सकता था
  • यह vulnerability Android 16 networking stack की QUIC connection termination feature से उत्पन्न हुई थी, और सामान्य app केवल standard permissions के साथ UDP payload को system_server में register कर सकता था
  • जब app का UDP socket नष्ट हो जाता है, तो privileged system_server संग्रहीत payload को VPN tunnel के बजाय सीधे physical network interface पर भेज देता है, जिससे VPN lock protection bypass हो जाती है
  • Google ने इस issue को “Won’t Fix (Infeasible)” और “NSBC” के रूप में वर्गीकृत किया, और माना कि यह Android security advisory के मानदंडों को पूरा नहीं करता, इसलिए उसने अपनी पुरानी स्थिति बरकरार रखी
  • GrapheneOS ने release 2026050400 में “registerQuicConnectionClosePayload optimization” को disable कर दिया, और इसके साथ मई 2026 Android security patch, hardened_malloc improvements, Linux kernel updates, और libpng CVE-2026-33636 backport fix भी शामिल किए

vulnerability कैसे काम करती है

  • Yusuf के तकनीकी विश्लेषण के अनुसार, vulnerable API ने केवल auto-granted INTERNET और ACCESS_NETWORK_STATE permissions वाले सामान्य app को system_server में arbitrary UDP payload register करने की अनुमति दी
  • इसके बाद जब app का UDP socket नष्ट हो जाता है, तो Android का privileged system_server process संग्रहीत payload को VPN tunnel की जगह डिवाइस के physical network interface पर सीधे भेज देता है
  • क्योंकि system_server elevated networking permissions के साथ चलता है और VPN routing restrictions से बाहर है, यह packet Android की VPN lock protection को पूरी तरह bypass कर देता है
  • security researcher lowlevel/Yusuf ने Proton VPN और Android lock mode दोनों चालू किए हुए Android 16 आधारित Pixel 8 पर इस vulnerability का प्रदर्शन किया
  • संबंधित app ने VPN protection पूरी तरह सक्रिय होने के बावजूद डिवाइस का वास्तविक public IP address एक remote server तक लीक कर दिया

कारण और Google की प्रतिक्रिया

  • Google ने ऐसा feature पेश किया था ताकि socket अनपेक्षित रूप से नष्ट होने पर application QUIC session को सामान्य रूप से बंद कर सके
  • implementation arbitrary payload स्वीकार कर रही थी, लेकिन यह verify नहीं कर रही थी कि payload वैध QUIC CONNECTION_CLOSE frame है या नहीं
  • implementation यह भी मूल रूप से check नहीं कर रही थी कि application केवल VPN-only traffic तक सीमित है या नहीं
  • researcher ने यह issue Android security team को report किया, लेकिन Google ने इसे “Won’t Fix (Infeasible)” और “NSBC” (Not Security Bulletin Class) के रूप में वर्गीकृत किया
  • Google ने माना कि यह issue Android security advisory में शामिल किए जाने के मानदंडों को पूरा नहीं करता
  • researcher ने दोबारा समीक्षा का अनुरोध करते हुए कहा कि standard permissions के साथ कोई भी app identifiable network information लीक कर सकता है, लेकिन Google ने अपनी पुरानी स्थिति बरकरार रखी और 29 अप्रैल को disclosure को मंजूरी दी

GrapheneOS अपडेट और mitigation

  • GrapheneOS Google Pixel devices के लिए मुख्य रूप से विकसित एक privacy और security केंद्रित Android-आधारित operating system है, जिसका उपयोग वे लोग करते हैं जो अधिक मजबूत application sandboxing, exploit mitigation, और Google services पर कम निर्भरता चाहते हैं
  • GrapheneOS ने release 2026050400 में इस optimization को पूरी तरह disable कर VPN leak को रोक दिया
  • Yusuf ने कहा कि GrapheneOS ने एक सप्ताह से भी कम समय में fix जारी कर दिया
  • नवीनतम release में VPN leak fix के अलावा पूरा मई 2026 Android security patch level भी शामिल है
  • अपडेट में कई hardened_malloc improvements, Android की 6.1, 6.6 और 6.12 branches में Linux kernel updates, और libpng के CVE-2026-33636 का backport fix शामिल है
  • नया Vanadium browser build और विस्तारित Dynamic Code Loading restrictions भी साथ में दिए गए हैं
  • सामान्य Android उपयोगकर्ता ADB के जरिए close_quic_connection DeviceConfig flag को disable करके अस्थायी रूप से इस issue को mitigate कर सकते हैं
  • इस workaround के लिए developer access की आवश्यकता होती है
  • यदि Google भविष्य के अपडेट में इस feature flag को हटा देता है, तो यह mitigation आगे कायम नहीं रह सकती

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

1 टिप्पणियां

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

  • अगर system_server ऊँचे network permissions के साथ चलता है और VPN routing restrictions से बाहर है, तो Android में VPN असल में VPN है ही नहीं ऐसा लगता है
    इस bug से अलग, यह जानने की जिज्ञासा है कि क्या दूसरे locked-down operating systems भी इसी तरह काम करते हैं

    • iOS भी ऐसा ही है, और इसे bypass करने के लिए 250+ devices वाले enterprise license की ज़रूरत पड़ती है, ऐसा मुझे पता है
      Mullvad वगैरह ने भी इस समस्या पर बहुत पहले बात की थी
    • “private” या “trust” जैसे शब्दों का मतलब computer world और इंसानी परंपराओं में अलग होता है
      चिंता इस बात की है कि लोग एक ही spelling वाले शब्द देखकर context का फर्क नहीं समझते, और इंसानी भरोसे को गलत तरीके से computer trust model तक बढ़ा देते हैं
    • macOS में भी ऐसे मामले रहे हैं जहाँ उसके अपने apps always-on VPN को bypass कर सकते थे
      यह नहीं पता कि arbitrary destinations पर सीधे traffic भेजने वाली कोई vulnerability या loophole भी थी या नहीं
    • यह जानने की उत्सुकता है कि system_server और दूसरे bypass paths को ठीक करना कितना मुश्किल है

  • Manifest V3 की तरह, snooping को रोकना Google के हित में नहीं है
    ऐसी पाबंदियाँ उसके business model को नुकसान पहुँचाती हैं

  • इस समस्या के गंभीर technical कारणों में एक यह है कि leak privileged process system_server से होता है
    Android का अपना lockdown mode साफ़ तौर पर वादा करता है कि कोई भी traffic VPN को bypass नहीं करेगा। अगर system खुद physical interface पर packets भेजता है, तो यह वादा user space में नहीं बल्कि kernel level पर टूटता है, इसलिए इसे “security advisory के लायक नहीं” कहना मुश्किल है

  • अगर Google ने 29 अप्रैल को disclosure की अनुमति दे दी थी, तो यह हैरानी की बात है कि तब भी embargo रखा गया और fix release को मई तक टाला गया
    समझ नहीं आता कि तुरंत public क्यों नहीं किया गया

    • एक vendor के रूप में Google के साथ संबंध खराब न करने की कोशिश रही होगी
      पसंद हो या न हो, GrapheneOS Google-controlled Android पर निर्भर है

  • समझ आता है कि इसके पीछे खराब business reasons हो सकते हैं, लेकिन VPN leak को security issue नहीं मानकर कोई अपना सम्मान कैसे बचा सकता है, समझ नहीं आता

    • यह इस पर निर्भर करता है कि VPN की भूमिका को आप कैसे देखते हैं
      मूल रूप से VPN का उपयोग किसी दूसरे network के जरिए private network या office network तक पहुँचने के लिए होता था, जैसे offices के बीच link या घर से office access। बाद में यह एक तरह के security tool जैसा बन गया
      अगर VPN code को “फोन 5G से office printer तक पहुँच जाए, बस इतना काफी है” की तरह देखें, तो यह QUIC connection के सही तरह बंद न होने वाला छोटा bug हो सकता है। लेकिन अगर आप इसे “यह WireGuard tunnel हर हाल में मेरी पहचान बचाए” या “यह internet पर गए हर traffic की सटीक copy होना चाहिए” की तरह देखते हैं, तो यह बड़ी समस्या है
      मेरा मानना है कि Android VPN, या लगभग कोई भी VPN, privacy/security mechanism के रूप में डिज़ाइन नहीं किया गया था। खासकर उन apps के खिलाफ तो बिल्कुल नहीं जो device पर code चला सकते हैं, और device खुद भी modem chip के अंदर समेत कई तरह के network interactions करता है
      Google से bug बंद हो गया, यह अच्छी बात है, लेकिन bug bounty program में इसे security bug न मानने की वजह समझ में आती है
    • यह सवाल तभी पूछा जा सकता है जब मान लिया जाए कि बचाने लायक सम्मान है
    • Google के नज़रिए से यह bug नहीं, feature है
      Google एक ad company भी है और attack contractor भी, इसलिए VPN users का packets leak करना दोनों ही वजहों से उसके लिए फायदेमंद है
    • उसे इसके लिए पैसे मिलते हैं
    • जो व्यक्ति personal information के unwanted exposure को security issue मानता हो, वह शायद Google में काम नहीं कर सकता

  • यह कुछ वैसा ही है जैसे Meta end-to-end encryption हटा दे
    ज़्यादा करीब बात यह है: “नहीं, हम चाहते हैं कि तुम जो कुछ कहते और करते हो, वह सब हम देखें”

  • GrapheneOS फोन पाने का अच्छा तरीका क्या है, यह जानना चाहता हूँ
    GrapheneOS आज़माना चाहता था, लेकिन असली Pixel खरीदने में हिचक है। Used market में भी “a” series आम तौर पर 300 डॉलर से ऊपर है, और तब भी कई generations पीछे जाना पड़ता है। यह भी समस्या है कि bootloader unlock हो पाएगा या नहीं। नए Pixel 10a पर 449 डॉलर खर्च करना अभी मुश्किल है

    • अभी शायद इससे मदद न मिले, लेकिन GrapheneOS ने हाल ही में Motorola के साथ partnership घोषित की है, इसलिए शायद एक साल के भीतर कुछ Motorola devices का support आना शुरू हो जाए
      संदर्भ के लिए, Google Fi launch के समय मैंने Pixel 10a करीब 300 डॉलर में खरीदा था
    • Pixel 10a न खरीदना ही बेहतर है
      Pixel 9a लगभग वही device है और अभी भी नया मिल रहा है
    • Pixel 8 series या उसके बाद की सिफारिश है
      carrier store के बजाय सामान्य retail store या Google Store से नया खरीदना ज़्यादा सुरक्षित है
      used device लेना OEM unlock handling की वजह से जुए जैसा है, इसलिए return policy अच्छी है या नहीं यह देखें और खरीदने से पहले verify करें कि OEM unlock उपलब्ध है
    • दूसरे thread में जवाब दिया था: https://news.ycombinator.com/item?id=48076522
      मूल रूप से Pixel 6 या उसके बाद का ऐसा device खरीदना है जिसमें bootloader unlock निश्चित रूप से संभव हो। लेकिन Pixel 6 जल्दी ही केवल minimal support पर रह जाएगा, इसलिए Pixel 7 या बाद का सुझाव है। ज़्यादातर used listings में bootloader unlock नहीं हो पाता
      यानी Google से सीधे खरीदना, या eBay पर पहले से GrapheneOS/CalyxOS/LineageOS installed device लेना, या ऐसा device लेना जिसके seller ने साफ़ कहा हो कि bootloader unlock संभव है, बेहतर है
      व्यक्तिगत अनुभव में, अगर seller ने पहले से नहीं बताया हो तो उससे bootloader check करने को कहना बेकार ही रहा। लगभग कोई भी verification process से गुजरना नहीं चाहता, जवाब आम तौर पर “नहीं” होने की संभावना रहती है, लोग सवाल को गलत समझकर बस “unlocked phone” कह सकते हैं, या ऐसे सवालों से थक चुके होते हैं
    • थोड़ा इंतज़ार करना भी एक तरीका है
      ज़्यादा phone hardware support करने का काम चल रहा है, और कुछ समय तक यह अंदाज़े का विषय था कि वह कौन-सा brand होगा

  • GrapheneOS आज़माने के लिए मैंने सस्ता used Pixel 6 खरीदा, लेकिन अनुभव खास पसंद नहीं आया
    LineageOS का user experience मुझे कहीं बेहतर लगा। Package manager की बनावट Russian dolls जैसी अजीब लगती है। Default “App Store” में बस कुछ basic programs हैं, जिनमें से एक Accrescent नाम का दूसरा package manager है, लेकिन उसमें भी apps बहुत कम हैं, इसलिए फिर एक और package manager चाहिए। GrapheneOS की तरफ़ से F-Droid के बजाय Obtainium को पसंद किया जाता है, जो भी अजीब फैसला लगता है
    मैं पूरी तरह open source package manager को बहुत ज़्यादा पसंद करता हूँ, और GitHub packages पर भरोसा करने के बजाय बाहर source से build करना, और जहाँ संभव हो reproducible builds रखना, इसमें असली मूल्य है। GrapheneOS का security model कुछ अजीब तरह से केंद्रीकृत लगता है। Report की गई privacy और security advantages को खुद आँकना मुश्किल है

    • F-Droid सीधे download कर लो, बस
      समझ नहीं आता कि preinstalled, तयशुदा app store पर इतना ज़ोर क्यों है
      App store चलाना Android fork को maintain करने जितना ही मेहनत का काम है, और जब F-Droid, Play Store, Aurora Store, Obtainium जैसे कई विकल्प पहले से हैं, तो GrapheneOS developers पर यह आरोप लगाना कठिन है कि वे इसमें भारी मेहनत नहीं लगा रहे
    • App Store को apps कहाँ से लेने हैं, यह तय करने के लिए न्यूनतम शुरुआती बिंदु जैसा समझो
      Default state में launcher और न्यूनतम operating system के अलावा कुछ नहीं है, और minimalist लोगों के लिए वही काफी है
      अगर और कुछ चाहिए तो user खुद तय करे कि कहाँ जाना है। मैं इसे user को power देना कहूँगा, और आप शायद इसे असुविधा कह रहे हैं। अगर ऐसा है, तो हो सकता है वह operating system आपके लिए सही न हो
    • कोई software सिर्फ इसलिए कि वह free/open source है, अपने-आप ज़्यादा सुरक्षित या ज़्यादा private नहीं हो जाता
      “open source” मूल रूप से licensing term है
      GrapheneOS का “App Store” सामान्य उपयोग के लिए ज़रूरी सबसे बुनियादी apps देने के लिए है। Accrescent वहाँ इसलिए दिया जाता है क्योंकि एक वास्तविक app repository के रूप में वह Android के security baseline का पालन करता है, जबकि F-Droid और Aurora Store ऐसा नहीं करते
      मुझे नहीं लगता कि F-Droid जैसे third party द्वारा apps build करके malicious behavior चेक करने के मॉडल में बहुत मूल्य है। ऐसी जाँच भरोसेमंद नहीं होती और कई बार bypass भी हुई है। WireGuard अब F-Droid पर नहीं होने की एक वजह यह भी है। अगर आप किसी app पर इतना भी भरोसा नहीं कर सकते कि उसे developer से सीधे लें, तो शायद वह app इस्तेमाल ही नहीं करना चाहिए
      GrapheneOS के privacy और security benefits को औसत user के लिए लगभग अदृश्य रहने के हिसाब से डिज़ाइन किया गया है। उदाहरण के लिए memory corruption bugs को रोकने के लिए hardened memory allocator और memory tagging extension, और sandboxed Google Play install करने की क्षमता ताकि Google services इस्तेमाल हो सकें लेकिन Google पूरे device को control न कर सके
    • GrapheneOS ने Android Open Source Project का user interface inherit किया है, और Pixel का stock operating system तथा कई manufacturers के Android forks भी इसी पर आधारित हैं
      GrapheneOS का App Store, AOSP की माँग के अनुसार primary app store की भूमिका निभाने के लिए मौजूद है। यह primary apps को operating system updates से अलग update करने और कुछ मामलों में apps को mirror करने का भी काम करता है
      Accrescent को privacy और security पर focus होने की वजह से mirror किया जाता है। यह फिलहाल alpha state में है और app submissions बंद हैं, लेकिन जल्द खुलने वाले हैं
      Google Play को उन apps की compatibility और Play Store access के लिए mirror किया जाता है जिन्हें Google Play चाहिए
      GrapheneOS community Obtainium को इसलिए पसंद करती है क्योंकि उससे GitHub जैसी जगहों से developer-signed apps लिए जा सकते हैं। F-Droid अपने main repository के लगभग सभी apps को पुराने build infrastructure और कमजोर coordination system के साथ sign और build करता है
      GrapheneOS का security model, AOSP security model को inherit करता है और उसके ऊपर अतिरिक्त hardening जोड़ता है
    • यह देखकर बहुत अच्छा लग रहा है कि CalyxOS फिर से सक्रिय हो रहा है
      GrapheneOS में शानदार technical implementations बहुत हैं, लेकिन Calyx कई चीज़ें अधिक सरल और stock Android के करीब तरीके से करता दिखता है

  • GrapheneOS का कहना है कि “VPN leak fix” के लिए उसने registerQuicConnectionClosePayload optimization को disable किया और supported Pixel devices पर attack vector को लगभग निष्प्रभावी बना दिया
    यानी GrapheneOS ने optimization बंद करके leak को “ठीक” किया
    पहले HN पर QUIC की काफ़ी तारीफ़ होती थी, और जो comments पूछते थे कि QUIC से सबसे ज़्यादा फायदा किसे होता है उन्हें downvote किया जाता था। QUIC का इस्तेमाल दूसरों के हित में हो सकता है, लेकिन मेरे लिए यह trade-off सही नहीं है, इसलिए मैं QUIC traffic block करता हूँ
    QUIC Android जैसे Google-distributed software में default on हो सकता है, और कुछ मामलों में इसे बंद करने का कोई तरीका भी नहीं होता

    • GrapheneOS में QUIC खुद अभी भी ठीक से काम करता है
      GrapheneOS ने केवल यह तरीका हटाया है जिसमें app crash होने जैसी स्थिति में operating system से QUIC connection को अपने-आप बंद करने का अनुरोध किया जा सकता था। Server की नज़र से यह optimization है, क्योंकि connection खुला छोड़कर resources पकड़े रहने और फिर idle timeout के बाद shutdown process चलाने से बचा जा सकता है, लेकिन client side optimization नहीं है
      इसके अलावा GrapheneOS ने लगभग 5 और VPN leaks भी ठीक किए हैं और आगे भी fixes जारी हैं। Android का मौजूदा VPN implementation profile-based VPN है, लेकिन profiles अभी अपने अलग network namespace का उपयोग नहीं करते, और DNS resolver तथा कई central services को VPN support सही तरह संभालना पड़ता है, इसलिए leaks की संभावना रहती है
      आगे VPN architecture को बेहतर बनाकर उसे leaks के खिलाफ बहुत मज़बूत करने की योजना है। Apps या app groups को virtual machines में चलाने का support भी आएगा, जो और मज़बूत सुरक्षा दे सकता है
    • यह QUIC connections को graceful तरीके से बंद करने वाला path था, जो गलत या दुरुपयोग योग्य call के ज़रिए expose हो गया था; ऐसा नहीं कि GrapheneOS ने पूरे QUIC को disable कर दिया हो
      QUIC खुद बेहतरीन है, और यह protocol की नहीं बल्कि surveillance OS, यानी Google Android की feature के ज़्यादा करीब है
      ऊपर से, latest release से पहले वाले operating system पर जाँचने पर भी यह ठीक से काम नहीं कर रहा था

  • Stock Android spyware भी है और adware भी
    पहले ऐसे software को malicious कहा जाता और हटा दिया जाता, लेकिन अब यही default बन गया है

    • सब सहमत हैं, लेकिन समाधान क्या है यह पता नहीं
      जब 99% users को परवाह ही नहीं, तो दबाव डालने की जगह सिर्फ phone manufacturers ही बचते हैं। लेकिन इस क्षेत्र में जिनके पास असली प्रभाव है, उन पर असर डालने की ताकत अपने पास न होने से बेबसी महसूस होती है