Une vulnérabilité d’exécution de code arbitraire dans KDE Plasma casse le sandboxing

• Un PoC confirme qu’en raison du comportement de gestion des fenêtres de KDE Plasma, une application sandboxée peut, à la suite d’un clic de l’utilisateur, exécuter un binaire arbitraire de l’hôte
• La cause principale est que KWin fait confiance à l’app_id fourni par l’application et conserve un chemin d’exécution basé sur /proc/PID/cmdline, sans correspondance réelle avec un fichier .desktop
• Le PoC reproduit un flux où /usr/bin/kcalc est exécuté hors du sandbox en combinant un hôte Arch Linux, une application Flatpak et une version modifiée de Mesa eglgears_wayland
• Lorsque l’utilisateur choisit Open New Window sur l’icône de la barre des tâches ou effectue un clic du milieu, le processus cible démarre dans le cgroup app.slice et avec l’espace de noms de montage de l’hôte exposé
• Pour atténuer le problème, il faut vérifier l’ID de l’application dans le security context du sandbox, XdpAppInfo et les control groups, et empêcher l’ouverture d’une nouvelle fenêtre pour les fenêtres qui ne correspondent pas à un fichier .desktop

---

Le flux d’évasion du sandbox montré par le PoC

• Une application sandboxée malveillante peut se faire passer pour une autre application et exécuter un binaire arbitraire sur l’hôte au moment où l’utilisateur déclenche Open New Window
• Le PoC a été reproduit avec Flatpak, mais l’analyse indique qu’il pourrait s’appliquer à d’autres sandbox, qu’ils prennent ou non en charge les contextes de sécurité
• La configuration de test est la suivante
  • Hôte Arch Linux
  • Dépendances de build wget, unzip, meson
  • Application Flatpak sans permissions accordées io.github.johannesboehler2.BmiCalculator
  • Comme la compilation dans le sandbox n’est pas simple, seul le chemin du binaire malveillant est transmis à Flatpak
  • Binaire cible désigné /usr/bin/kcalc
• Lorsque le binaire malveillant est exécuté, une icône KCalc apparaît dans la barre des tâches
• Si l’utilisateur fait un clic droit puis choisit Open New Window, /usr/bin/kcalc démarre hors du sandbox
  • L’emplacement d’exécution est le cgroup app.slice
  • L’espace de noms de montage est celui de l’hôte
  • En conséquence, il s’exécute dans un état totalement exposé

Processus de découverte et indices

• Lors de tests d’un sandbox Portable dans KDE Plasma avec une machine virtuelle QEMU, certaines fenêtres n’étaient pas associées au fichier .desktop approprié et apparaissaient dans la barre des tâches avec une icône Wayland générique
• Ce phénomène a été signalé sous le titre KWin trusts on Apps fully for app_id, et conduit au problème permettant à une application d’en usurper une autre
• Par la suite, un clic du milieu effectué par erreur dans la barre des tâches a déclenché Open New Window comme action par défaut
• Une nouvelle fenêtre s’est bien lancée, mais elle n’utilisait pas les identifiants de connexion enregistrés ni les paramètres modifiés ; en comparant le PID de la KWin Debug Console avec les control groups et les informations rootfs de procfs, l’évasion du sandbox est apparue

Fonctionnement de la vulnérabilité

• Même si KWin ne parvient pas à relier une fenêtre à un vrai fichier .desktop, il conserve un chemin permettant de trouver l’argv0 à exécuter
• Les résultats de l’expérience ont confirmé l’hypothèse selon laquelle la valeur est lue via /proc/PID/cmdline
• Le problème ne se limite pas au lancement d’une instance d’application existante hors du sandbox
• Tous les processus, y compris ceux sans privilèges, peuvent modifier argv0
  • Les espaces de noms de montage peuvent aussi être une option, mais sont décrits comme moins flexibles
• L’absence de protection de l’app_id fourni par l’application, combinée au caractère non sûr de la lecture de /proc/PID/cmdline, permet l’exécution de code arbitraire sur l’hôte

Démo et scénario d’attaque réel

• Le code de démonstration a été écrit par GalaxySnail et utilise eglgears-wayland de Mesa
• Le flux de démonstration est le suivant
  • Cloner le dépôt mesa-demos-argv0
  • Modifier la commande désignée dans la fonction main de src/egl/opengl/eglgears.c avec la commande souhaitée
  • Construire avec meson setup build && meson compile -C build
  • Exécuter ./build/src/egl/opengl/eglgears_wayland
  • Faire un clic du milieu sur l’icône de la barre des tâches ou choisir Open New Window dans le menu contextuel
  • Le binaire malveillant désigné démarre
• Dans une attaque réelle, il est possible de créer un script shell sous $HOME
  • $HOME se trouve généralement au même chemin sur l’hôte
  • L’application malveillante peut remplacer silencieusement argv0 par un binaire créé ou téléchargé
  • Si l’utilisateur clique sur Open New Window ou fait par erreur un clic du milieu sur l’icône de l’application, il est possible de prendre le contrôle complet de la session

Pistes de correction proposées

• Pour empêcher cet exploit, KDE Plasma ne doit pas faire confiance tel quel à l’ID fourni par l’application
• Il est proposé de récupérer l’ID de l’application depuis les chemins suivants
  • Le security context du sandbox
  • XdpAppInfo
  • Les control groups
• Si une fenêtre donnée ne correspond pas à un fichier .desktop, Open New Window ne devrait pas être autorisé
• Aucune mise à jour n’a été reçue de la part de KDE Security

Chronologie de la divulgation

• Dans le premier e-mail, « arbitrary code execution » a été désigné à tort comme RCE
• Tous les événements sont en UTC+8, au format 24 heures
• 1er avril 2026 à 23:51, premier e-mail envoyé à [e-mail]
• 2 avril 2026 à 00:15, David Edmundson répond pour confirmer le signalement
• 2 avril 2026 à 00:24, David Edmundson répond qu’il pense que cette fonctionnalité utilise le champ Exec= du fichier .desktop et ne peut pas servir à exécuter du code arbitraire
• 2 avril 2026 à 11:59, avec l’aide de GalaxySnail, confirmation qu’un autre PoC ne dépendant pas du fichier .desktop fonctionne
• 2 avril 2026 à 18:26, e-mail de suivi envoyé à [e-mail] avec les fichiers d’exploit et une explication, mais sans réponse reçue
• 2 mai 2026 à 11:59, confirmation que l’exploit n’est pas corrigé dans Plasma 6.7 Beta
• 2 juillet 2026 à 18:30, divulgation effectuée après que l’exploit est resté actif au-delà du délai d’attente de 90 jours
• La divulgation a été décidée pour sensibiliser, après l’absence de correctif et de réponse de suivi, et une fois le délai habituel de 90 jours écoulé
• Il est ajouté qu’il ne s’agit pas de critiquer les développeurs de KDE ; les projets OSS subissent récemment beaucoup de spam et les humains ont eux aussi une capacité de traitement limitée, mais le processus peut être amélioré

[GN⁺]

Avis sur Lobste.rs

• J’aurais vraiment aimé que la tentative Capsicum pour Linux ne meure pas à cause du NIH
  Pour le sandboxing des apps desktop, c’est un modèle bien meilleur que tout l’empilement de bricolages qu’on a accumulés sous Linux pour essayer d’obtenir la même chose. Le lanceur fournit, à partir des métadonnées, l’ensemble initial de permissions — autrement dit des descripteurs de fichiers — et l’application ne peut accéder à rien d’autre ; une powerbox fournit ensuite les autorisations pour ouvrir ou enregistrer d’autres fichiers
  • Tout le modèle de conteneurs de Linux ressemble un peu à un assemblage bancal de concepts
    Il convient globalement aux environnements où un processus quasi divin orchestre des services, comme un service Kubernetes, mais il s’adapte mal au desktop. On veut pouvoir entrer, depuis l’espace utilisateur, dans un cgroup/namespace avec moins de privilèges, mais il faut passer par un rituel avec un démon root ou du setuid, ce qui finit par introduire un risque d’élévation de privilèges
  • En théorie, les principaux outils de sandboxing desktop sous Linux, comme Flatpak, devraient fonctionner ainsi en prenant SCM_RIGHTS + Wayland + D-Bus comme briques de base
    En plissant les yeux, on distingue bien les contours d’un desktop sécurisé
    Mais les implémentations réelles sont, dans l’ensemble, beaucoup trop permissives, trop rigides ou à moitié cassées. On dirait que personne ne se soucie de la sécurité desktop de bout en bout autant que de la sécurité des workloads serveur. Résultat, gVisor et Firecracker fonctionnent bien, alors que Flatpak a du mal à lancer une simple application Gtk+ sans casser les polices, et chaque compositeur Wayland doit réimplémenter la moitié d’une base de desktop fiable
    C’est d’autant plus embarrassant quand on pense qu’Android a plutôt bien réussi à être une distribution Linux suffisamment durcie pour exécuter du code non fiable, et qu’iOS comme macOS ont montré que le sandboxing des applications destinées aux utilisateurs pouvait aussi être suffisamment pratique à utiliser. Il suffirait de faire comme eux. Pourquoi diable quelque chose dans un gestionnaire de fenêtres lit-il /proc/{pid}/cmdline ?
• Le fait que cela ait débouché sur une divulgation publique après que l’upstream n’a pas réussi à publier de correctif ne donne pas une bonne image
  Ce n’est absolument pas une critique envers le chercheur
• Je ne sais pas si le rapport d’issue envoyé à l’upstream était formulé de cette manière, mais c’était assez difficile à suivre
  Je pense que j’aurais beaucoup mieux compris si j’avais été plus familier avec l’architecture interne de KDE ou de Flatpak