Kerentanan Eksekusi Kode Arbitrer yang Menembus Sandbox di KDE Plasma

• Karena perilaku manajemen jendela KDE Plasma, sebuah PoC memastikan bahwa aplikasi yang berjalan di sandbox dapat, dengan dipicu klik pengguna, menjalankan biner arbitrer di host
• Penyebab utamanya adalah KWin memercayai app_id yang diberikan aplikasi, dan masih menyisakan jalur eksekusi berbasis /proc/PID/cmdline tanpa pencocokan dengan file .desktop yang sebenarnya
• PoC mereproduksi alur di mana /usr/bin/kcalc dijalankan di luar sandbox dengan kombinasi host Arch Linux, aplikasi Flatpak, dan Mesa eglgears_wayland yang dimodifikasi
• Saat pengguna memilih Open New Window pada ikon taskbar atau melakukan klik tengah, proses target dimulai dalam keadaan terekspos pada cgroup app.slice dan mount namespace host
• Untuk mitigasi, ID aplikasi perlu diverifikasi dari security context sandbox, XdpAppInfo, dan control groups, serta eksekusi jendela baru harus diblokir untuk jendela yang tidak cocok dengan file .desktop

---

Alur pelarian dari sandbox yang ditunjukkan PoC

• Aplikasi sandbox berbahaya dapat menyamar sebagai aplikasi lain dan menjalankan biner arbitrer di host pada saat pengguna memanggil Open New Window
• PoC direproduksi dengan Flatpak, tetapi dirangkum bahwa ini juga dapat berlaku pada sandbox lain terlepas dari ada tidaknya dukungan konteks keamanan
• Konfigurasi eksperimennya sebagai berikut
  • Host Arch Linux
  • Dependensi build wget, unzip, meson
  • Aplikasi Flatpak tanpa izin io.github.johannesboehler2.BmiCalculator
  • Karena build di dalam sandbox tidak mudah, hanya jalur biner berbahaya yang diteruskan ke Flatpak
  • Biner target yang ditentukan /usr/bin/kcalc
• Saat biner berbahaya dijalankan, ikon KCalc ditampilkan di taskbar
• Jika pengguna melakukan klik kanan lalu memilih Open New Window, /usr/bin/kcalc dimulai di luar sandbox
  • Lokasi eksekusinya adalah cgroup app.slice
  • Mount namespace berada di sisi host
  • Akibatnya, program berjalan dalam keadaan sepenuhnya terekspos

Proses penemuan dan petunjuknya

• Saat menguji sandbox Portable sebagai mesin virtual QEMU di KDE Plasma, sebagian jendela tidak terhubung ke file .desktop yang sesuai sehingga ditampilkan di taskbar sebagai ikon Wayland umum
• Fenomena ini dilaporkan sebagai KWin trusts on Apps fully for app_id, dan mengarah pada masalah di mana aplikasi dapat menyamar sebagai aplikasi lain
• Setelah itu, ketika tidak sengaja melakukan klik tengah di taskbar, tindakan default Open New Window terpanggil
• Jendela baru memang berjalan, tetapi tidak menggunakan kredensial login yang tersimpan maupun pengaturan yang telah dimodifikasi; dengan memeriksa PID di KWin Debug Console bersama informasi control groups dan rootfs dari procfs, pelarian dari sandbox pun terungkap

Cara kerja kerentanan

• Walaupun KWin gagal menghubungkan jendela ke file .desktop yang sebenarnya, masih ada jalur untuk menemukan argv0 yang akan dieksekusi
• Hasil eksperimen menunjukkan dugaan bahwa nilainya dibaca melalui /proc/PID/cmdline adalah benar
• Masalahnya tidak berhenti pada menjalankan instance aplikasi yang sudah ada di luar sandbox
• Semua proses, termasuk proses tanpa hak istimewa, dapat mengubah argv0
  • Mount namespace juga bisa menjadi opsi, tetapi dirangkum kurang fleksibel
• Ketiadaan perlindungan terhadap app_id yang diberikan aplikasi, dipadukan dengan ketidakamanan pembacaan /proc/PID/cmdline, memungkinkan eksekusi kode arbitrer di host

Demo dan skenario serangan nyata

• Kode demo ditulis oleh GalaxySnail, menggunakan eglgears-wayland dari Mesa
• Alur demonya sebagai berikut
  • Clone repositori mesa-demos-argv0
  • Ubah perintah yang ditentukan di dalam fungsi main pada src/egl/opengl/eglgears.c menjadi perintah yang diinginkan
  • Build dengan meson setup build && meson compile -C build
  • Jalankan ./build/src/egl/opengl/eglgears_wayland
  • Klik tengah ikon taskbar atau pilih Open New Window dari menu konteks
  • Biner berbahaya yang ditentukan akan dimulai
• Dalam serangan nyata, memungkinkan untuk membuat skrip shell di bawah $HOME
  • $HOME umumnya juga berada pada jalur yang sama di host
  • Aplikasi berbahaya dapat diam-diam membuat argv0 atau menggantinya dengan biner yang diunduh
  • Jika pengguna mengeklik Open New Window atau tidak sengaja melakukan klik tengah pada ikon aplikasi, sesi dapat dikendalikan sepenuhnya

Arah perbaikan yang diusulkan

• Agar KDE Plasma dapat mencegah eksploit ini, ID yang diberikan aplikasi tidak boleh dipercaya begitu saja
• Diusulkan agar ID aplikasi diperoleh dari jalur berikut
  • security context sandbox
  • XdpAppInfo
  • control groups
• Jika jendela tertentu tidak cocok dengan file .desktop, Open New Window seharusnya tidak diizinkan
• Belum ada pembaruan yang diterima dari email KDE Security

Linimasa publikasi

• Dalam email asli, arbitrary code execution keliru ditulis sebagai RCE
• Semua peristiwa berdasarkan UTC+8, format 24 jam
• 1 April 2026 23:51, email pertama dikirim ke [e-mail]
• 2 April 2026 00:15, David Edmundson membalas untuk mengonfirmasi laporan
• 2 April 2026 00:24, David Edmundson membalas bahwa fitur tersebut menggunakan Exec= dari file .desktop dan menurutnya tidak dapat digunakan untuk eksekusi kode arbitrer
• 2 April 2026 11:59, dengan bantuan GalaxySnail, dikonfirmasi bahwa PoC lain yang tidak bergantung pada file .desktop berhasil berjalan
• 2 April 2026 18:26, email lanjutan berisi file eksploit dan penjelasan dikirim ke [e-mail], tetapi tidak mendapat respons
• 2 Mei 2026 11:59, dikonfirmasi bahwa eksploit belum dipatch di Plasma 6.7 Beta
• 2 Juli 2026 18:30, karena eksploit masih aktif dan masa tunggu 90 hari telah terlewati, publikasi dilakukan
• Karena belum dipatch, tidak ada balasan lanjutan, dan masa tunggu umum 90 hari telah berlalu, diputuskan untuk mempublikasikannya demi meningkatkan kesadaran
• Ditambahkan bahwa ini bukan upaya mengkritik pengembang KDE; proyek OSS belakangan ini mengalami banyak spam dan manusia pun memiliki batas kapasitas pemrosesan, tetapi prosesnya masih bisa ditingkatkan

[GN⁺]

Komentar Lobste.rs

• Sayang sekali upaya menghadirkan Capsicum untuk Linux seperti mati karena NIH
  Untuk sandboxing aplikasi desktop, ini adalah model yang jauh lebih baik daripada berbagai pendekatan tambal-sulam yang sekarang ditumpuk di Linux untuk mencoba melakukan hal serupa. Launcher menyerahkan himpunan izin awal berdasarkan metadata, yaitu file descriptor, dan aplikasi tidak bisa mengakses apa pun selain itu, sementara powerbox menyediakan izin tambahan untuk membuka/menyimpan file lain
  • Seluruh model container di Linux terlihat seperti tempelan konsep-konsep yang agak canggung
    Secara umum cocok untuk lingkungan tempat suatu proses seperti dewa mengorkestrasi layanan, seperti layanan Kubernetes, tetapi kurang cocok untuk desktop. Di ruang pengguna kita ingin masuk ke cgroup/namespace dengan hak lebih rendah, tetapi harus melewati ritual seperti daemon root atau setuid, yang pada akhirnya menimbulkan risiko eskalasi hak istimewa
  • Secara teori, alat sandbox desktop Linux utama seperti Flatpak seharusnya bekerja seperti ini dengan SCM_RIGHTS + Wayland + D-Bus sebagai elemen dasarnya
    Kalau dilihat sambil memicingkan mata, bentuk desktop yang aman memang tampak
    Tetapi implementasi nyatanya secara umum terlalu longgar, terlalu kaku, atau setengah rusak. Tidak terlihat ada yang benar-benar peduli pada keamanan desktop end-to-end sebesar perhatian orang pada pengamanan beban kerja server. Akibatnya gVisor dan Firecracker berjalan baik, tetapi Flatpak sulit bahkan untuk menjalankan satu aplikasi Gtk+ bawaan tanpa merusak font, dan semua compositor Wayland harus mengimplementasikan ulang setengah dari fondasi desktop yang dapat dipercaya
    Ini makin memalukan jika mengingat Android cukup berhasil berperan sebagai distribusi Linux yang cukup diperkeras untuk menjalankan kode tak tepercaya, dan iOS serta macOS telah menunjukkan bahwa sandboxing aplikasi yang berhadapan langsung dengan pengguna juga bisa cukup nyaman dipakai. Tinggal lakukan saja seperti yang mereka lakukan. Kenapa sesuatu di dalam window manager membaca /proc/{pid}/cmdline
• Tidak enak dilihat karena berujung pada full disclosure setelah upstream gagal menambal
  Ini sama sekali bukan kritik terhadap penelitinya
• Saya tidak tahu apakah laporan issue yang dikirim ke upstream juga ditulis seperti ini, tetapi cukup sulit diikuti
  Mungkin akan jauh lebih mudah dipahami kalau lebih akrab dengan struktur internal KDE atau Flatpak