The Deathray: एक अविश्वसनीय साइट के लिए Mac को फ्रीज़ करने का एक सरल तरीका

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

एक नया WebGPU exploit केवल एक विशेष रूप से तैयार webpage पर जाकर macOS मशीनों—और कुछ Android devices—को reliably freeze कर सकता है, और कुछ मामलों में hard reboots तथा browsers के auto-restore tabs के कारण बार-बार lockups तक मजबूर कर सकता है। Commenters बहस करते हैं कि क्या इस तरह के denial-of-service को गंभीर security vulnerability माना जाना चाहिए, यह देखते हुए कि ransomware-style scams, data loss, और उन non-technical users को नुकसान पहुँचाने की संभावना है जो कारण आसानी से नहीं पहचान सकते। यह घटना web को अधिक से अधिक GPU और hardware features देने की बढ़ती आलोचना को भी हवा देती है, जहाँ performance और rich web apps का टकराव increased attack surface और system instability से होता है।

देखा गया व्यवहार और गंभीरता

  • कई macOS उपयोगकर्ता पूरी सिस्टम हैंग की रिपोर्ट करते हैं: कर्सर हिल सकता है लेकिन UI, Force Quit, और इनपुट अनुत्तरदायी हो जाते हैं; अक्सर हार्ड पावर-ऑफ़ की ज़रूरत पड़ती है।
  • कुछ Macs पर यह सिर्फ Safari या टैब को ही बंद कर देता है; ब्राउज़र को तुरंत quit करने पर सामान्य संचालन वापस आ जाता है।
  • कुछ चरम रिपोर्टें: ऑटो-रीस्टोर किए गए टैब्स के कारण लॉगिन पर बार-बार क्रैश; एक उपयोगकर्ता शुरू में safe mode में भी बूट नहीं कर सका और रिकवरी से पहले अपडेट/reinstall की ज़रूरत पड़ी।
  • गैर-mac व्यवहार मिश्रित है:
    • कुछ Windows ब्राउज़र सिर्फ टैब या सभी टैब्स को थोड़ी देर के लिए फ्रीज़ करते हैं, फिर दोषी पेज को मार देते हैं।
    • कुछ Android डिवाइस (जैसे Pixel, Samsung) कथित तौर पर हार्ड-फ्रीज़ हो जाते हैं; अलग ब्राउज़रों या hardened OS builds वाले अन्य डिवाइस केवल थोड़े stutter या कुछ भी नहीं देखते।
    • Linux/Firefox के मामले एक क्रैश हुए ब्राउज़र से लेकर बिना किसी दिखाई देने वाले प्रभाव तक फैले हुए हैं।
  • iOS को अप्रभावित बताया गया है; macOS 27 RC अभी भी प्रभावित है।

सुरक्षा और threat model पर बहस (DoS)

  • इस बात की प्रबल चिंता है कि ब्राउज़र-ट्रिगर किया गया reliable freeze एक सार्थक denial-of-service है और इसलिए एक सुरक्षा समस्या है।
  • दुरुपयोग के सुझाए गए मामले: scareware (“आपका कंप्यूटर वायरस के कारण फ्रीज़ हो गया”), ransom-style “हम आपको तब तक फ्रीज़ करते रहेंगे जब तक…”, ad-tech coercion (“adblock बंद करो वरना हम आपकी मशीन crash कर देंगे”), ज़्यादा विश्वसनीय fake-AV scams क्योंकि मशीन सचमुच फ्रीज़ हुई थी।
  • दूसरों का तर्क है कि यह “सिर्फ availability” है, कोई डेटा चोरी या privilege escalation नहीं, इसलिए कम प्राथमिकता है।
  • उपयोगकर्ता व्यवहार पर असहमति:
    • एक पक्ष दावा करता है कि यह “self-correcting” है क्योंकि उपयोगकर्ता उन साइटों से बचते हैं जो उन्हें फ्रीज़ करती हैं।
    • दूसरे कहते हैं कि सामान्य उपयोगकर्ता freeze ↔ site को नहीं जोड़ेंगे, auto-restore loops में फँस सकते हैं, या “tech support” scammers को कॉल करने के लिए प्रेरित हो सकते हैं।

ज़िम्मेदारी: OS vs browser vs WebGPU

  • कुछ लोग इसे मुख्यतः macOS bug के रूप में देखते हैं: अन्य OS में GPU watchdogs होते हैं जो misbehaving workloads को reset कर देते हैं; macOS अभी भी GPU hangs को पूरे सिस्टम/WindowServer को नीचे ले जाने देता है।
  • अन्य इसे WebGPU/WebGL में अंतर्निहित मानते हैं: OS का व्यवहार कैसा भी हो, web को कभी भी मशीन को lock नहीं करना चाहिए।
  • thread नोट करता है कि Apple ने इसी तरह के WebGPU मुद्दों को “not security relevant” कहकर बंद किया है।

WebGPU और web as app platform पर व्यापक विचार

  • संशयवादी पक्ष:
    • ब्राउज़र में hardware attack surface के लगातार फैलने (WebGPU, WebUSB, आदि) की चिंता।
    • तर्क कि ब्राउज़र documents के लिए थे, पूर्ण application/runtime layer के रूप में नहीं, और हम Java applets / Flash / ActiveX जैसी गलतियाँ दोहरा रहे हैं।
    • कुछ उपयोगकर्ता security/privacy के लिए WebGPU/WebGL को पूरी तरह disable कर देते हैं, rich apps के नुकसान को स्वीकार करते हुए।
  • समर्थन/स्वीकार करने वाला पक्ष:
    • नोट करता है कि desktops पर native app distribution असुरक्षित और fragmented है; ब्राउज़र एक de facto cross-platform sandbox और permission model प्रदान करते हैं।
    • बताते हैं कि कई modern apps (Figma, Canva, Maps-like tools) WebGL/WebGPU पर निर्भर करते हैं; इन्हें बंद करना बड़ा regression है।
    • कुछ तर्क देते हैं कि WebGPU, WebGL की तुलना में fingerprinting surface को अर्थपूर्ण रूप से अधिक नहीं बढ़ाता।

GPU architecture और तकनीकी नोट्स

  • यह व्याख्या कि GPUs में अक्सर fine-grained, OS-level preemption नहीं होती:
    • बड़ा, महँगा state; shared registers और memory लंबे समय तक चलने वाले shaders को interrupt करना कठिन बनाते हैं।
    • कई डिज़ाइन cooperative yielding या coarse-grained boundaries पर निर्भर करते हैं, इसलिए tight loop device पर पूरा कब्ज़ा कर सकता है।
  • shader loop limits पर चर्चा: ऐतिहासिक रूप से, finite loops लागू/unrolled किए जाते थे; general control flow के साथ, timeout-based protection का उपयोग किया जाता है।
  • WebGPU implementations कभी-कभी loop termination “guarantee” करने के लिए विशाल down-counters inject करते हैं, लेकिन counter इतना बड़ा होता है कि loop खत्म होने से बहुत पहले भी system hang हो सकता है।
  • यह अवलोकन कि एक साधारण compute shader loop सिर्फ tab को crash कर सकता है, जबकि उसे waiting render passes के साथ जोड़ने पर WindowServer प्रभावित होता है; canvas को offscreen करने से व्यवहार बदल जाता है, जो compositing path में जटिल interactions का संकेत देता है।

चर्चित mitigations और workarounds

  • WebGPU को global रूप से या per-browser disable करें; कई Firefox उपयोगकर्ता बताते हैं कि वे पहले से ऐसा कर रहे हैं।
  • ऐसे ब्राउज़र उपयोग करें जो:
    • crashed sessions को restore करने से पहले prompt करें, या
    • सभी restored tabs को auto-load किए बिना शुरू करने दें।
  • यदि auto-restore loop में फँस जाएँ: जैसे ही ब्राउज़र का icon दिखे, तुरंत quit करें, या अस्थायी रूप से network disconnect करें; network disconnect की प्रभावशीलता पर बहस है, खासकर service workers के साथ।
  • सुझाव कि extensions untrusted sites पर WebGPU APIs को no-ops में stub कर सकते हैं।
  • कुछ लोग hardened browsers/OSes (जैसे GrapheneOS Vanadium) पर निर्भर हैं, जो अधिक gracefully recover करते प्रतीत होते हैं।

ऐतिहासिक समानताएँ और anecdotes

  • पहले के “fun” या malicious web tricks के अनेक संदर्भ:
    • infinite alert() loops, popup storms, और shock sites जो audio बजाते थे और windows spam करते थे।
    • पुराने Unicode या Wi-Fi SSID bugs जो iOS devices को crash कर सकते थे।
    • browser pages जो infinite logging या भारी 3D scenes के माध्यम से memory/DevTools पर दबाव डालते थे।
  • कुछ लोग वर्तमान bug को browser-driven DoS की लंबे समय से मौजूद श्रेणी का हिस्सा मानते हैं, और नोट करते हैं कि वर्षों पहले WebGL और OpenCL के साथ similar GPU hangs मौजूद थे।