KDE Plasma’da sandbox’ı kıran rastgele kod çalıştırma açığı

• KDE Plasma’nın pencere yönetimi davranışı nedeniyle, sandbox içindeki bir uygulamanın kullanıcının tıklamasını tetikleyici olarak kullanıp host üzerinde rastgele bir ikili dosya çalıştırabildiği PoC ile doğrulandı
• Temel neden, KWin’in uygulamanın sağladığı app_id değerine güvenmesi ve gerçek .desktop dosyası eşleştirmesi olmadan /proc/PID/cmdline tabanlı çalıştırma yolunu açık bırakması
• PoC, Arch Linux host’u, bir Flatpak uygulamasını ve değiştirilmiş Mesa eglgears_wayland’i birleştirerek /usr/bin/kcalc’in sandbox dışında çalıştırıldığı akışı yeniden üretiyor
• Kullanıcı görev çubuğu simgesinde Open New Window seçeneğini seçtiğinde veya orta tıkladığında, hedef süreç app.slice cgroup’u ve host mount namespace’i içinde görünür halde başlatılıyor
• Hafifletme için sandbox’ın security context’i, XdpAppInfo ve control groups üzerinden uygulama kimliği doğrulanmalı; .desktop dosyasıyla eşleşmeyen pencerelerde yeni pencere çalıştırma engellenmeli

---

PoC’nin gösterdiği sandbox’tan kaçış akışı

• Kötü niyetli bir sandbox uygulaması, kullanıcının Open New Window çağırdığı anda başka bir uygulama gibi davranarak host üzerinde rastgele bir ikili dosya çalıştırabilir
• PoC Flatpak ile yeniden üretildi, ancak güvenlik bağlamı desteği olup olmamasından bağımsız olarak başka sandbox’lara da uygulanabileceği belirtiliyor
• Deney kurulumu şöyle
  • Arch Linux host’u
  • Derleme bağımlılıkları wget, unzip, meson
  • Hiçbir izin verilmemiş Flatpak uygulaması io.github.johannesboehler2.BmiCalculator
  • Sandbox içinde derleme kolay olmadığı için Flatpak’e yalnızca kötü niyetli ikili dosyanın yolu iletildi
  • Belirlenen hedef ikili dosya /usr/bin/kcalc
• Kötü niyetli ikili dosya çalıştırıldığında görev çubuğunda KCalc simgesi gösteriliyor
• Kullanıcı sağ tıklayıp Open New Window seçeneğini seçtiğinde /usr/bin/kcalc sandbox dışında başlatılıyor
  • Çalıştırıldığı yer app.slice cgroup’u
  • Mount namespace host tarafında
  • Sonuç olarak tamamen açıkta çalışıyor

Keşif süreci ve ipuçları

• KDE Plasma’da Portable sandbox QEMU sanal makinesiyle test edilirken, bazı pencerelerin uygun .desktop dosyasıyla ilişkilendirilmediği ve görev çubuğunda genel Wayland simgesi olarak göründüğü fark edildi
• Bu durum KWin trusts on Apps fully for app_id olarak bildirildi ve uygulamaların başka uygulamaların kimliğine bürünebilmesi sorununa yol açtı
• Daha sonra görev çubuğunda yanlışlıkla orta tıklanınca varsayılan davranış olarak Open New Window çağrıldı
• Yeni pencere açıldı, ancak kayıtlı oturum açma kimlik bilgilerini ve değiştirilmiş ayarları kullanmadı; KWin Debug Console’daki PID ile procfs’teki control groups ve rootfs bilgileri birlikte incelendiğinde sandbox’tan kaçış ortaya çıktı

Açığın çalışma şekli

• KWin pencereyi gerçek bir .desktop dosyasına bağlayamasa bile, çalıştırılacak argv0 değerini bulmaya yönelik bir yol kalıyor
• Deney sonuçları, değerin /proc/PID/cmdline üzerinden okunduğu tahminini doğruladı
• Sorun yalnızca mevcut uygulama örneğini sandbox dışında çalıştırmakla sınırlı değil
• Yetkisiz süreçler dahil tüm süreçler argv0 değerini değiştirebilir
  • Mount namespace de bir seçenek olabilir, ancak daha az esnek olduğu belirtiliyor
• Uygulamanın sağladığı app_id için koruma olmaması ile /proc/PID/cmdline okumanın güvensizliği birleşerek host üzerinde rastgele kod çalıştırmayı mümkün kılıyor

Demo ve gerçek saldırı senaryosu

• Demo kodu GalaxySnail tarafından yazıldı ve Mesa’nın eglgears-wayland aracını kullanıyor
• Demo akışı şöyle
  • mesa-demos-argv0 deposunu klonlama
  • src/egl/opengl/eglgears.c içindeki main fonksiyonunda belirtilen komutu istenen komutla değiştirme
  • meson setup build && meson compile -C build ile derleme
  • ./build/src/egl/opengl/eglgears_wayland çalıştırma
  • Görev çubuğu simgesine orta tıklama veya bağlam menüsünden Open New Window seçme
  • Belirlenen kötü niyetli ikili dosya başlatılır
• Gerçek bir saldırıda $HOME altında bir shell script oluşturma yöntemi kullanılabilir
  • $HOME genellikle host üzerinde de aynı yoldadır
  • Kötü niyetli uygulama argv0 değerini sessizce oluşturduğu veya indirdiği bir ikili dosyayla değiştirebilir
  • Kullanıcı Open New Window’a tıklarsa ya da yanlışlıkla uygulama simgesine orta tıklarsa oturumun tam kontrolü ele geçirilebilir

Önerilen düzeltme yönü

• KDE Plasma’nın bu exploit’i engellemesi için uygulamanın sağladığı kimliğe olduğu gibi güvenmemesi gerekir
• Uygulama kimliğinin şu yollardan elde edilmesi öneriliyor
  • Sandbox’ın security context’i
  • XdpAppInfo
  • control groups
• Belirli bir pencere .desktop dosyasıyla eşleşmiyorsa Open New Window’a izin verilmemeli
• KDE Security e-postasından henüz güncelleme alınmamış durumda

Açıklama zaman çizelgesi

• İlk e-postada arbitrary code execution yanlışlıkla RCE olarak yazılmıştı
• Tüm olaylar UTC+8, 24 saat formatına göredir
• 1 Nisan 2026 23:51’de ilk e-posta [e-mail] adresine gönderildi
• 2 Nisan 2026 00:15’te David Edmundson raporu aldığını belirten bir yanıt gönderdi
• 2 Nisan 2026 00:24’te David Edmundson, bu özelliğin .desktop dosyasındaki Exec= değerini kullandığını ve rastgele kod çalıştırmak için kullanılamayacağını düşündüğünü belirten bir yanıt verdi
• 2 Nisan 2026 11:59’da GalaxySnail yardımıyla .desktop dosyasına dayanmayan başka bir PoC’nin çalıştığı doğrulandı
• 2 Nisan 2026 18:26’da exploit dosyası ve açıklamaları içeren takip e-postası [e-mail] adresine gönderildi, ancak yanıt alınmadı
• 2 Mayıs 2026 11:59’da exploit’in Plasma 6.7 Beta’da yamalanmadığı doğrulandı
• 2 Temmuz 2026 18:30’da exploit aktif durumdayken 90 günlük bekleme süresi aşıldığı için açıklama yapıldı
• Yamalanmadığı, takip yanıtı alınmadığı ve olağan 90 günlük bekleme süresi geçtiği için farkındalık yaratmak amacıyla açıklama yapılmasına karar verildi
• Bunun KDE geliştiricilerini eleştirme girişimi olmadığı; OSS projelerinin son dönemde spam’den muzdarip olduğu ve insanların da işlem kapasitesinin sınırlı olduğu, ancak sürecin iyileştirilebileceği eklendi

[GN⁺]

Lobste.rs yorumları

• Linux için Capsicum girişiminin NIH yüzünden ölmemiş olmasını gerçekten isterdim
  Masaüstü uygulama sandbox’lama için, şu anda Linux’ta aynı şeyi yapmaya çalışırken üst üste yığılan türlü yöntemlerden çok daha iyi bir model. Launcher, metadata’ya dayanarak başlangıçtaki yetki kümesini, yani dosya descriptor’larını geçiriyor; uygulama bunun dışında hiçbir şeye erişemiyor ve powerbox başka dosyaları açma/kaydetme izinlerini sağlıyor
  • Linux’un tüm container modeli biraz derme çatma kavramların yamalı bohçası gibi görünüyor
    Kubernetes servisleri gibi, neredeyse tanrısal bir sürecin servisleri orkestre ettiği ortamlar için genel olarak uygun; ama masaüstünde pek iyi oturmuyor. Kullanıcı alanında daha düşük yetkili bir cgroup/namespace içine girmek istiyorsunuz, ama root daemon ya da setuid gibi ritüellerden geçmeniz gerekiyor; bu da sonunda ayrıcalık yükseltme riskini beraberinde getiriyor
  • Teoride Flatpak gibi başlıca Linux masaüstü sandbox araçlarının SCM_RIGHTS + Wayland + D-Bus’ı temel yapı taşları olarak kullanıp böyle çalışması gerekir
    Gözlerinizi biraz kısınca güvenli bir masaüstünün ana hatları seçiliyor
    Ama gerçek uygulamalar genel olarak ya fazla izin verici, ya esneklikten yoksun, ya da yarı bozuk. Uçtan uca masaüstü güvenliğini, sunucu iş yüklerinin güvenliği kadar önemseyen kimse yok gibi görünüyor. Bu yüzden gVisor ve Firecracker iyi çalışırken Flatpak, en basit Gtk+ uygulamasını bile fontları bozmadan çalıştırmakta zorlanıyor; ayrıca her Wayland compositor’ının güvenilir bir masaüstü temelinin yarısını yeniden uygulaması gerekiyor
    Android’in, güvenilmeyen kodu çalıştıracak kadar güçlendirilmiş bir Linux dağıtımı rolünü oldukça iyi yerine getirdiğini; iOS ve macOS’in de kullanıcıya dönük uygulama sandbox’lamasının yeterince kullanışlı olabileceğini gösterdiğini düşününce bu daha da utanç verici. Sadece onların yaptığı gibi yapmak yeterli. Peki bir pencere yöneticisinin içindeki bir şey neden /proc/{pid}/cmdline okuyor ki
• Upstream’in yamalayamamasının ardından kamuya açık ifşaya gidilmiş gibi görünüyor; pek iyi durmuyor
  Bu söz kesinlikle araştırmacıya yönelik bir eleştiri değil
• Upstream’e gönderilen issue raporu da böyle miydi bilmiyorum ama takip etmesi epey zordu
  KDE ya da Flatpak’in iç yapısına daha aşina olsaydım muhtemelen çok daha iyi anlardım