KDE Plasma में sandbox तोड़ने वाली arbitrary code execution भेद्यता

• KWin के window management व्यवहार के कारण यह PoC से पुष्टि हुई कि sandboxed app, उपयोगकर्ता के क्लिक के ट्रिगर पर host arbitrary binary चला सकता है
• मुख्य कारण यह है कि KWin app द्वारा दिए गए app_id पर भरोसा करता है, और वास्तविक .desktop file matching के बिना /proc/PID/cmdline-आधारित execution path छोड़ा गया है
• PoC, Arch Linux host, Flatpak app, और संशोधित Mesa eglgears_wayland को मिलाकर /usr/bin/kcalc के sandbox के बाहर चलने वाले flow को पुन: प्रस्तुत करता है
• जब उपयोगकर्ता taskbar icon पर Open New Window चुनता है या middle click करता है, तो target process app.slice cgroup और host mount namespace में exposed स्थिति में शुरू होता है
• mitigation के लिए sandbox के security context, XdpAppInfo, और control groups में app ID की पुष्टि करनी होगी, और .desktop file से मेल न खाने वाली windows के लिए new window launch को रोकना होगा

---

PoC ने जो sandbox escape flow दिखाया

• malicious sandboxed app, उपयोगकर्ता द्वारा Open New Window बुलाते ही किसी दूसरे app का रूप धरकर host पर arbitrary binary चला सकता है
• PoC को Flatpak पर पुन: प्रस्तुत किया गया, लेकिन इसमें कहा गया है कि security context support हो या न हो, यह अन्य sandboxes पर भी लागू हो सकता है
• प्रयोग का setup इस प्रकार है
  • Arch Linux host
  • build dependency wget, unzip, meson
  • बिना permission दिए Flatpak app io.github.johannesboehler2.BmiCalculator
  • sandbox के भीतर build करना आसान न होने के कारण केवल malicious binary path Flatpak को दिया गया
  • निर्दिष्ट target binary /usr/bin/kcalc
• malicious binary चलाने पर taskbar में KCalc icon दिखाई देता है
• उपयोगकर्ता right-click के बाद Open New Window चुनता है तो /usr/bin/kcalc sandbox के बाहर शुरू हो जाता है
  • execution location app.slice cgroup
  • mount namespace host side का
  • नतीजतन यह पूरी तरह exposed स्थिति में चलता है

खोज की प्रक्रिया और सुराग

• KDE Plasma में Portable sandbox को QEMU virtual machine से test करते समय यह देखा गया कि कुछ windows उचित .desktop file से जुड़ी नहीं थीं, इसलिए taskbar में सामान्य Wayland icon के रूप में दिख रही थीं
• इस घटना को KWin trusts on Apps fully for app_id के रूप में report किया गया, और यह ऐसी समस्या तक जाता है जिसमें app किसी दूसरे app का रूप धर सकता है
• इसके बाद taskbar में गलती से middle click करने पर default व्यवहार के रूप में Open New Window बुलाया गया
• नई window चली, लेकिन उसने saved login credentials और modified settings का उपयोग नहीं किया, और KWin Debug Console के PID को procfs के control groups और rootfs जानकारी के साथ मिलाकर देखने पर sandbox escape सामने आया

भेद्यता कैसे काम करती है

• भले ही KWin किसी window को वास्तविक .desktop file से जोड़ न पाए, फिर भी executable argv0 खोजने का path बचा रहता है
• प्रयोग के नतीजों से यह अनुमान सही निकला कि मान /proc/PID/cmdline के जरिए पढ़ा जाता है
• समस्या केवल मौजूदा application instance को sandbox के बाहर चलाने तक सीमित नहीं है
• unprivileged process सहित सभी process argv0 को बदल सकते हैं
  • mount namespace भी एक विकल्प हो सकता है, लेकिन इसे कम flexible बताया गया है
• app द्वारा दिए गए app_id के लिए सुरक्षा का अभाव और /proc/PID/cmdline पढ़ने की असुरक्षा मिलकर host पर arbitrary code execution संभव बनाते हैं

डेमो और वास्तविक attack scenario

• demo code GalaxySnail ने लिखा है, और इसमें Mesa का eglgears-wayland उपयोग होता है
• demo flow इस प्रकार है
  • mesa-demos-argv0 repository clone करें
  • src/egl/opengl/eglgears.c की main function के भीतर निर्दिष्ट command को इच्छित command से बदलें
  • meson setup build && meson compile -C build से build करें
  • ./build/src/egl/opengl/eglgears_wayland चलाएँ
  • taskbar icon पर middle click करें या context menu से Open New Window चुनें
  • निर्दिष्ट malicious binary शुरू हो जाएगा
• वास्तविक attack में $HOME के नीचे shell script बनाने का तरीका संभव है
  • $HOME आमतौर पर host पर भी वही path होता है
  • malicious app, argv0 को चुपचाप बनाए गए या download किए गए binary से बदल सकता है
  • जब उपयोगकर्ता Open New Window पर click करता है या गलती से app icon पर middle click करता है, तो session पर पूरा control लिया जा सकता है

प्रस्तावित fix की दिशा

• KDE Plasma को इस exploit को रोकने के लिए app द्वारा दिए गए ID पर ज्यों का त्यों भरोसा नहीं करना चाहिए
• सुझाव है कि app ID निम्न path से लिया जाए
  • sandbox का security context
  • XdpAppInfo
  • control groups
• यदि कोई specific window .desktop file से match नहीं करती, तो Open New Window की अनुमति नहीं देनी चाहिए
• KDE Security mail से कोई update नहीं मिला है

सार्वजनिक disclosure timeline

• मूल mail में arbitrary code execution को गलती से RCE लिखा गया था
• सभी event UTC+8, 24-hour format के आधार पर हैं
• 1 अप्रैल 2026 23:51, पहला mail [e-mail] पर भेजा गया
• 2 अप्रैल 2026 00:15, David Edmundson ने report की पुष्टि करते हुए जवाब भेजा
• 2 अप्रैल 2026 00:24, David Edmundson ने जवाब दिया कि उनका मानना है कि यह feature .desktop file के Exec= का उपयोग करता है और इसे arbitrary code execution के लिए इस्तेमाल नहीं किया जा सकता
• 2 अप्रैल 2026 11:59, GalaxySnail की मदद से यह पुष्टि हुई कि .desktop file पर निर्भर न करने वाला दूसरा PoC काम करता है
• 2 अप्रैल 2026 18:26, exploit file और विवरण सहित follow-up mail [e-mail] पर भेजा गया, लेकिन कोई जवाब नहीं मिला
• 2 मई 2026 11:59, Plasma 6.7 Beta में exploit के patch न होने की पुष्टि हुई
• 2 जुलाई 2026 18:30, exploit के active रहते हुए 90 दिन की waiting period पार होने पर disclosure किया गया
• patch न होने, follow-up reply न मिलने, और सामान्य 90 दिन की waiting period बीतने के बाद awareness बढ़ाने के लिए disclosure का निर्णय लिया गया
• यह KDE developers की आलोचना करने का प्रयास नहीं है; साथ में यह भी जोड़ा गया कि OSS project हाल में spam से जूझ रहे हैं और इंसानों की processing capacity की सीमाएँ होती हैं, लेकिन process बेहतर हो सकता है

[GN⁺]

Lobste.rs की राय

• काश Linux के लिए Capsicum का प्रयास NIH की वजह से बंद न हुआ होता
  डेस्कटॉप ऐप sandboxing के लिए यह Linux पर अभी जो इसी तरह की चीज़ करने के लिए अलग-अलग तरीकों का ढेर लगाया गया है, उससे कहीं बेहतर मॉडल है। launcher metadata के आधार पर शुरुआती अधिकारों का सेट, यानी file descriptors, देता है और ऐप उसके अलावा किसी चीज़ तक पहुँच नहीं सकता, जबकि powerbox दूसरी फ़ाइलों को खोलने/सेव करने की अनुमति देता है
  • Linux का पूरा container मॉडल थोड़ा ढीले-ढाले concepts की जोड़-तोड़ जैसा लगता है
    Kubernetes services जैसी किसी दैवी process द्वारा services को orchestrate करने वाले environment में यह आम तौर पर ठीक बैठता है, लेकिन डेस्कटॉप पर उतना फिट नहीं बैठता। user space में और कम अधिकार वाले cgroup/namespace में जाना हो, तो root daemon या setuid जैसी रस्मों से गुजरना पड़ता है, जो आख़िरकार privilege escalation का जोखिम बुलाती हैं
  • सैद्धांतिक रूप से Flatpak जैसे प्रमुख Linux डेस्कटॉप sandbox tools को SCM_RIGHTS + Wayland + D-Bus को बुनियादी building blocks बनाकर इसी तरह काम करना चाहिए
    थोड़ा आँखें सिकोड़कर देखें तो सुरक्षित डेस्कटॉप की रूपरेखा दिखती है
    लेकिन असली implementation कुल मिलाकर या तो बहुत permissive है, या inflexible, या आधी-टूटी हुई है। लगता है end-to-end डेस्कटॉप security की उतनी चिंता कोई नहीं करता जितनी server workloads की security की करता है। इसलिए gVisor और Firecracker अच्छी तरह काम करते हैं, लेकिन Flatpak में एक साधारण Gtk+ ऐप को भी fonts बिगाड़े बिना चलाना मुश्किल है, और हर Wayland compositor को भरोसेमंद डेस्कटॉप foundation का आधा हिस्सा फिर से implement करना पड़ता है
    यह देखते हुए और भी शर्मनाक लगता है कि Android ने untrusted code चलाने लायक काफ़ी hardened Linux distribution की भूमिका काफ़ी अच्छी तरह निभाई है, और iOS व macOS ने दिखाया है कि user-facing app sandboxing पर्याप्त रूप से usable भी हो सकती है। बस वे जैसा करते हैं वैसा कर लेना चाहिए। आख़िर window manager के अंदर कोई चीज़ /proc/{pid}/cmdline क्यों पढ़ रही है
• upstream के patch न कर पाने के बाद मामला public disclosure तक पहुँचना अच्छा नहीं लगता
  इसका मतलब शोधकर्ता की किसी भी तरह से आलोचना करना बिल्कुल नहीं है
• पता नहीं upstream को भेजी गई issue report भी ऐसी ही थी या नहीं, लेकिन इसे follow करना काफ़ी मुश्किल था
  अगर KDE या Flatpak की internal structure से ज़्यादा परिचित होता, तो शायद इसे बहुत बेहतर समझ पाता