Zero click, silent, remote Android DoS

मूल लेख ↗ Hacker News चर्चा ↗

हाल ही में disclosed एक Android vulnerability एक single malformed WAP Push SMS को system phone process को बार-बार crash कराने देती है, जिससे active calls (including emergency calls) user interaction के बिना गिर जाती हैं और devices call करने में असमर्थ हो सकते हैं जब तक SIM को किसी दूसरे handset में न ले जाया जाए। Commenters इस denial-of-service risk की वास्तविक गंभीरता, real networks पर ऐसे messages भेजना कितना आसान है, और क्या carriers या fake base stations इसे बड़े पैमाने पर weaponize कर सकते हैं, इस पर बहस करते हैं। बातचीत का एक बड़ा हिस्सा AI-generated “hypey” write-up और Google की initial “won’t fix” triage की आलोचना भी करता है, यह नोट करते हुए कि Google ने बाद में CVE assign किया और patch ship किया है (जो पहले ही GrapheneOS में शामिल है), संभवतः internal miscommunication के बाद।

भेद्यता और प्रभाव

  • विकृत WAP Push डेटा SMS (उदाहरण के लिए, पोर्ट 2948 पर) Android के com.android.phone को क्रैश कर सकती है, जिससे कॉलें, including emergency calls, बिना किसी user interaction या visible message के गिर जाती हैं।
  • बार-बार डिलीवरी एक internal SMS/telephony SQLite DB को corrupt कर सकती है, जिससे phone process हर boot पर crash करता है। डिवाइस effectively phone capability खो देता है जबकि Wi‑Fi अभी भी काम करता रहता है।
  • recovery का वर्णन इस तरह किया गया है: SIM/eSIM profile को किसी non-Android device पर move करें (ताकि pending messages ACK हो जाएँ), फिर corrupted DB को clean up करें (उदा. telephony.db delete करें) या factory reset करें। eSIM के लिए यह बहुत कठिन है।
  • कुछ लोग सवाल उठाते हैं कि क्या SQLite mid-write crash से corrupt हो जाना चाहिए; अन्य लोग कहते हैं कि उन्होंने व्यवहार में DB corruption देखी है।

Exploitability और Carriers की भूमिका

  • PoC APK दिया गया है जो एक device से किसी भी target phone number पर malformed SMS भेज सकता है; victim के local compromise की आवश्यकता नहीं है।
  • कई commenters, जिनके पास अनुभव है, कहते हैं कि non-user-visible SMS types (WAP Push, silent SMS, APN config, voicemail indicators) वास्तविक हैं और अक्सर filtered नहीं होते।
  • अन्य लोग skeptical हैं: यह स्पष्ट नहीं है कि arbitrary malformed WAP Push messages सभी carrier networks से गुजर सकते हैं या कुछ networks पहले से उन्हें filter या drop कर देते हैं।
  • चर्चा किए गए scenarios: personal harassment (उदा. किसी ex के खिलाफ), targeted disruption/suppression, या IMSI catchers / spoofed towers के साथ संयुक्त attacks।

Severity, Google की प्रतिक्रिया और patching

  • severity पर बहस: कुछ इसे “temporary DoS” और मामूली मानते हैं; अन्य जोर देते हैं कि remotely emergency calling को disable करना एक गंभीर security issue है।
  • Google ने शुरू में report को “won’t fix” / “not a security issue” के रूप में classify किया, संभवतः front-line triager के माध्यम से। इस पर आलोचना हुई और इसे broader quality decline तथा VRP overload का हिस्सा बताया गया।
  • बाद की टिप्पणियाँ बताती हैं कि Google ने वास्तव में June में fix commit किया, इसे July में security preview patches के माध्यम से ship किया, और यह November 2026 Android Security Bulletin में CVE‑2026‑58882 (Critical) के रूप में दिखाई देगा। पहले की closure को internal miscommunication/duplicate handling से जोड़ा गया है।
  • एक hardened Android fork रिपोर्ट करता है कि उसने fix महीनों पहले ship कर दिया था और पुष्टि करता है कि उसके अपने users प्रभावित नहीं हैं।

AI-Generated Write-Up और “Slop” बहस

  • कई टिप्पणियाँ landing page के AI-generated tone पर केंद्रित हैं: “hypeslop,” over-dramatic marketing language, और characteristic phrasing।
  • कुछ लोग तर्क देते हैं कि AI polish technical clarity को ढक देता है और credibility को नुकसान पहुँचाता है; अन्य लोग bug और PoC के real होने को देखते हुए layout/copy के लिए LLMs के उपयोग का बचाव करते हैं।
  • HN पर AI-generated vulnerability sites को upvote करने पर meta-discussion, जबकि “AI slop” की व्यापक शिकायतें भी हैं।