Vulnerabilidad de ejecución arbitraria de código que rompe el sandbox en KDE Plasma

• Un PoC confirmó que, debido al comportamiento de gestión de ventanas de KDE Plasma, una app en sandbox puede ejecutar un binario arbitrario del host a partir de una acción de clic del usuario
• La causa principal es que KWin confía en el app_id proporcionado por la app y dejó una ruta de ejecución basada en /proc/PID/cmdline sin verificar la coincidencia real con el archivo .desktop
• El PoC reproduce un flujo donde /usr/bin/kcalc se ejecuta fuera del sandbox combinando un host Arch Linux, una app Flatpak y un eglgears_wayland modificado de Mesa
• Si el usuario elige Open New Window en el ícono de la barra de tareas o hace clic central, el proceso objetivo se inicia expuesto dentro del cgroup app.slice y en el espacio de nombres de montaje del host
• Para mitigar el problema, se debe verificar el ID de la app a partir del contexto de seguridad del sandbox, XdpAppInfo y los control groups, y bloquear la apertura de nuevas ventanas cuando no coincidan con un archivo .desktop

---

Flujo de escape del sandbox mostrado por el PoC

• Una app maliciosa en sandbox puede hacerse pasar por otra app y ejecutar un binario arbitrario en el host en el momento en que el usuario invoque Open New Window
• Aunque el PoC se reprodujo con Flatpak, se concluye que también podría aplicarse a otros sandboxes independientemente de si admiten contexto de seguridad
• La configuración del experimento fue la siguiente
  • Host Arch Linux
  • Dependencias de compilación wget, unzip, meson
  • App Flatpak sin permisos io.github.johannesboehler2.BmiCalculator
  • Como no es fácil compilar dentro del sandbox, solo se pasó a Flatpak la ruta del binario malicioso
  • Binario objetivo designado /usr/bin/kcalc
• Al ejecutar el binario malicioso, en la barra de tareas aparece el ícono de KCalc
• Cuando el usuario hace clic derecho y selecciona Open New Window, /usr/bin/kcalc se inicia fuera del sandbox
  • La ubicación de ejecución es el cgroup app.slice
  • El espacio de nombres de montaje es el del host
  • Como resultado, se ejecuta completamente expuesto

Proceso de descubrimiento y pistas

• Mientras se probaban sandboxes portables en KDE Plasma con una máquina virtual QEMU, algunas ventanas no quedaban asociadas con su archivo .desktop correspondiente y aparecían en la barra de tareas con un ícono genérico de Wayland
• Este fenómeno fue reportado como KWin trusts on Apps fully for app_id, y deriva en un problema donde una app puede hacerse pasar por otra
• Después, al hacer clic central por error en la barra de tareas, se invocó Open New Window como comportamiento predeterminado
• La nueva ventana sí se ejecutó, pero no usó las credenciales de inicio de sesión guardadas ni la configuración modificada, y al revisar juntos el PID en la KWin Debug Console y la información de control groups y rootfs en procfs quedó en evidencia el escape del sandbox

Cómo funciona la vulnerabilidad

• Incluso si KWin no logra vincular una ventana con su archivo .desktop real, sigue existiendo una ruta para encontrar el argv0 a ejecutar
• Los experimentos confirmaron que era correcta la hipótesis de que el valor se lee a través de /proc/PID/cmdline
• El problema no se limita a ejecutar fuera del sandbox una instancia existente de la aplicación
• Todos los procesos, incluidos los procesos sin privilegios, pueden cambiar argv0
  • El espacio de nombres de montaje también podría usarse, pero se considera menos flexible
• La combinación entre la falta de protección del app_id provisto por la app y la lectura insegura de /proc/PID/cmdline hace posible la ejecución arbitraria de código en el host

Demo y escenarios de ataque reales

• El código de demostración fue escrito por GalaxySnail y utiliza eglgears-wayland de Mesa
• El flujo de la demo es el siguiente
  • Clonar el repositorio mesa-demos-argv0
  • Modificar el comando indicado dentro de la función main de src/egl/opengl/eglgears.c por el comando deseado
  • Compilar con meson setup build && meson compile -C build
  • Ejecutar ./build/src/egl/opengl/eglgears_wayland
  • Hacer clic central en el ícono de la barra de tareas o elegir Open New Window en el menú contextual
  • Se inicia el binario malicioso especificado
• En un ataque real, sería posible crear un script de shell bajo $HOME
  • $HOME normalmente también existe en la misma ruta en el host
  • La app maliciosa puede reemplazar argv0 de forma silenciosa por un binario creado o descargado
  • Si el usuario hace clic en Open New Window o pulsa por accidente el clic central sobre el ícono de la app, se puede tomar control completo de la sesión

Dirección propuesta para la corrección

• Para bloquear este exploit, KDE Plasma no debe confiar sin más en el ID proporcionado por la app
• Se propone obtener el ID de la app desde las siguientes rutas
  • El security context del sandbox
  • XdpAppInfo
  • Los control groups
• Si una ventana determinada no coincide con un archivo .desktop, no se debe permitir Open New Window
• No se ha recibido una actualización por parte del correo de seguridad de KDE

Cronología de la divulgación

• En el correo original se etiquetó incorrectamente arbitrary code execution como RCE
• Todos los eventos están en UTC+8 y en formato de 24 horas
• 1 de abril de 2026, 23:51: se envió el primer correo a [e-mail]
• 2 de abril de 2026, 00:15: David Edmundson respondió confirmando la recepción del reporte
• 2 de abril de 2026, 00:24: David Edmundson respondió que creía que esa función usaba Exec= del archivo .desktop y que no podría utilizarse para ejecución arbitraria de código
• 2 de abril de 2026, 11:59: con ayuda de GalaxySnail se confirmó que funcionaba otro PoC que no dependía del archivo .desktop
• 2 de abril de 2026, 18:26: se envió un correo de seguimiento a [e-mail] con el archivo del exploit y la explicación, pero no se recibió respuesta
• 2 de mayo de 2026, 11:59: se confirmó que el exploit no había sido corregido en Plasma 6.7 Beta
• 2 de julio de 2026, 18:30: al superar el período de espera de 90 días con el exploit todavía activo, se procedió a la divulgación pública
• Como no hubo parche, no llegó respuesta al seguimiento y ya había pasado el período habitual de espera de 90 días, se decidió publicar para generar conciencia
• Se aclara que no se busca criticar a los desarrolladores de KDE; aunque los proyectos OSS han sufrido recientemente por el spam y también existen límites humanos de capacidad de respuesta, el proceso puede mejorar

[GN⁺]

Opiniones en Lobste.rs

• Ojalá el intento de llevar Capsicum a Linux no hubiera muerto por NIH
  Es un modelo mucho mejor para el sandboxing de apps de escritorio que el montón de enfoques improvisados que hoy se han ido apilando en Linux para intentar hacer lo mismo. El lanzador entrega un conjunto inicial de capacidades basado en metadatos, es decir, descriptores de archivo, y la app no puede acceder a nada fuera de eso, mientras que un powerbox concede permisos adicionales para abrir o guardar otros archivos
  • Todo el modelo de contenedores de Linux se ve un poco como un parche de conceptos medio torpes
    Suele encajar en entornos donde algún proceso divino orquesta servicios, como en los servicios de Kubernetes, pero no queda bien en el escritorio. Uno quiere entrar desde espacio de usuario a un cgroup/namespace con menos privilegios, pero hay que pasar por rituales como un daemon root o setuid, y eso al final introduce riesgo de escalada de privilegios
  • En teoría, las principales herramientas de sandbox de escritorio en Linux, como Flatpak, deberían funcionar así usando SCM_RIGHTS + Wayland + D-Bus como piezas base
    Si entrecierras los ojos, sí se alcanza a ver la silueta de un escritorio seguro
    Pero las implementaciones reales en general son demasiado permisivas, o demasiado rígidas, o están medio rotas. No parece haber nadie tan preocupado por la seguridad de escritorio de extremo a extremo como sí lo están por asegurar cargas de trabajo de servidor. Por eso gVisor y Firecracker funcionan bien, pero en Flatpak cuesta hasta ejecutar una app básica de Gtk+ sin romper las fuentes, y todos los compositores de Wayland tienen que volver a implementar la mitad de la base de un escritorio confiable
    Da más pena todavía si se piensa que Android ha logrado bastante bien ser una distribución de Linux lo bastante reforzada como para ejecutar código no confiable, y que iOS y macOS han mostrado que el sandboxing de apps orientadas al usuario también puede ser suficientemente cómodo de usar. Simplemente hagan lo que ellos hacen. ¿Por qué demonios algo dentro del gestor de ventanas está leyendo /proc/{pid}/cmdline?
• Se ve mal que esto haya terminado en divulgación completa después de que upstream no pudo sacar un parche
  Esto no es en absoluto una crítica al investigador
• No sé si el reporte del issue enviado a upstream también era así, pero fue bastante difícil de seguir
  Seguramente habría sido mucho más fácil de entender si uno estuviera más familiarizado con la estructura interna de KDE o Flatpak