Beliebige-Codeausführungs-Schwachstelle durch Sandbox-Ausbruch in KDE Plasma

 (blog.kimiblock.top)
1 Punkte von GN⁺ 5 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Ein PoC zeigt, dass eine sandboxed App aufgrund des Fensterverwaltungsverhaltens von KDE Plasma durch einen Nutzerklick einen beliebigen Host-Binärdatei ausführen kann
  • Die Hauptursache ist, dass KWin die von der App gelieferte app_id vertraut und einen auf /proc/PID/cmdline basierenden Ausführungspfad beibehält, ohne Abgleich mit der tatsächlichen .desktop-Datei
  • Der PoC reproduziert mit einem Arch-Linux-Host, einer Flatpak-App und einem modifizierten Mesa-eglgears_wayland den Ablauf, bei dem /usr/bin/kcalc außerhalb der Sandbox ausgeführt wird
  • Wenn der Nutzer beim Taskleisten-Symbol Open New Window auswählt oder mit der mittleren Maustaste klickt, wird der Zielprozess mit sichtbarer app.slice-cgroup und Host-Mount-Namespace gestartet
  • Zur Abmilderung sollte die App-ID über den Security Context der Sandbox, XdpAppInfo und Control Groups geprüft werden, und für Fenster ohne passende .desktop-Datei sollte das Starten neuer Fenster blockiert werden

Der vom PoC gezeigte Ablauf des Sandbox-Ausbruchs

  • Eine bösartige sandboxed App kann in dem Moment, in dem der Nutzer Open New Window auslöst, sich als eine andere App ausgeben und auf dem Host eine beliebige Binärdatei ausführen
  • Der PoC wurde mit Flatpak reproduziert, soll laut Darstellung aber auch auf andere Sandboxes anwendbar sein, unabhängig davon, ob sie Security-Context-Unterstützung haben
  • Der Versuchsaufbau sieht wie folgt aus
    • Arch-Linux-Host
    • Build-Abhängigkeiten wget, unzip, meson
    • Unprivilegierte Flatpak-App io.github.johannesboehler2.BmiCalculator
    • Da ein Build innerhalb der Sandbox nicht einfach ist, wurde nur der Pfad zur bösartigen Binärdatei an Flatpak übergeben
    • Vorgesehene Ziel-Binärdatei /usr/bin/kcalc
  • Wird die bösartige Binärdatei ausgeführt, zeigt die Taskleiste das KCalc-Symbol an
  • Wählt der Nutzer per Rechtsklick Open New Window, startet /usr/bin/kcalc außerhalb der Sandbox
    • Der Ausführungsort ist die app.slice-cgroup
    • Der Mount-Namespace ist der des Hosts
    • Dadurch läuft der Prozess letztlich vollständig exponiert

Entdeckung und erste Hinweise

  • Beim Testen von Portable-Sandboxes in KDE Plasma in einer QEMU-VM fiel auf, dass manche Fenster keiner passenden .desktop-Datei zugeordnet wurden und daher in der Taskleiste als allgemeines Wayland-Symbol erschienen
  • Dieses Verhalten wurde als KWin trusts on Apps fully for app_id gemeldet und führt zu dem Problem, dass sich eine App als andere App ausgeben kann
  • Später wurde in der Taskleiste versehentlich mit der mittleren Maustaste geklickt, wodurch standardmäßig Open New Window ausgelöst wurde
  • Das neue Fenster wurde zwar gestartet, nutzte aber weder gespeicherte Login-Daten noch geänderte Einstellungen; durch die gemeinsame Prüfung von PID in der KWin Debug Console sowie Control Groups und rootfs in procfs wurde der Sandbox-Ausbruch sichtbar

So funktioniert die Schwachstelle

  • Selbst wenn KWin ein Fenster nicht mit einer tatsächlichen .desktop-Datei verknüpfen kann, bleibt ein Pfad bestehen, über den argv0 für den Start ermittelt wird
  • Experimente bestätigten die Vermutung, dass der Wert über /proc/PID/cmdline gelesen wird
  • Das Problem beschränkt sich nicht darauf, eine bestehende Anwendungsinstanz außerhalb der Sandbox zu starten
  • Jeder Prozess, auch ein unprivilegierter, kann argv0 ändern
    • Auch der Mount-Namespace wäre eine Option, wird aber als weniger flexibel beschrieben
  • Das Zusammenspiel aus fehlendem Schutz der von der App gelieferten app_id und dem unsicheren Lesen von /proc/PID/cmdline ermöglicht beliebige Codeausführung auf dem Host

Demo und reales Angriffsszenario

  • Der Demo-Code wurde von GalaxySnail geschrieben und verwendet Mesas eglgears-wayland
  • Der Demo-Ablauf ist wie folgt
    • Repository mesa-demos-argv0 klonen
    • In der main-Funktion von src/egl/opengl/eglgears.c den angegebenen Befehl in den gewünschten Befehl ändern
    • Mit meson setup build && meson compile -C build bauen
    • ./build/src/egl/opengl/eglgears_wayland ausführen
    • Auf das Taskleisten-Symbol mit der mittleren Maustaste klicken oder im Kontextmenü Open New Window wählen
    • Die festgelegte bösartige Binärdatei wird gestartet
  • In einem realen Angriff könnte stattdessen ein Shell-Skript unter $HOME erzeugt werden
    • $HOME ist in der Regel auf dem Host unter demselben Pfad vorhanden
    • Die bösartige App kann argv0 unauffällig auf eine erzeugte oder heruntergeladene Binärdatei umbiegen
    • Wenn der Nutzer Open New Window anklickt oder versehentlich mit der mittleren Maustaste auf das App-Symbol klickt, kann die Sitzung vollständig übernommen werden

Vorgeschlagene Richtung für einen Fix

  • Damit KDE Plasma diesen Exploit blockieren kann, sollte es der von der App gelieferten ID nicht unverändert vertrauen
  • Es wird vorgeschlagen, die App-ID aus folgenden Quellen zu beziehen
    • dem Security Context der Sandbox
    • XdpAppInfo
    • Control Groups
  • Wenn ein bestimmtes Fenster keiner .desktop-Datei zugeordnet werden kann, sollte Open New Window nicht erlaubt werden
  • Laut Text gab es von KDE Security dazu bislang kein Update

Offenlegungs-Timeline

  • In der ursprünglichen E-Mail wurde arbitrary code execution fälschlich als RCE bezeichnet
  • Alle Ereignisse sind in UTC+8 im 24-Stunden-Format angegeben
    1. April 2026, 23:51 Uhr: erste E-Mail an security@kde.org
    1. April 2026, 00:15 Uhr: David Edmundson bestätigt den Eingang des Berichts
    1. April 2026, 00:24 Uhr: David Edmundson antwortet, er gehe davon aus, dass die Funktion Exec= aus der .desktop-Datei verwende und daher nicht für beliebige Codeausführung missbraucht werden könne
    1. April 2026, 11:59 Uhr: Mit Hilfe von GalaxySnail wird bestätigt, dass ein anderer PoC funktioniert, der nicht von der .desktop-Datei abhängt
    1. April 2026, 18:26 Uhr: Eine Folge-E-Mail mit Exploit-Dateien und Beschreibung wird an security@kde.org gesendet, bleibt aber unbeantwortet
    1. Mai 2026, 11:59 Uhr: Es wird bestätigt, dass der Exploit in Plasma 6.7 Beta nicht gepatcht ist
    1. Juli 2026, 18:30 Uhr: Nach Überschreiten der 90-tägigen Wartefrist bei weiterhin aktivem Exploit erfolgt die Veröffentlichung
  • Da kein Patch vorlag, keine weitere Antwort einging und die übliche 90-Tage-Frist verstrichen war, fiel die Entscheidung zur Veröffentlichung, um das Bewusstsein zu erhöhen
  • Es sei nicht als Kritik an den KDE-Entwicklern gemeint; hinzugefügt wird, dass OSS-Projekte zuletzt unter Spam leiden und auch Menschen Grenzen bei der Bearbeitungskapazität haben, Prozesse aber verbessert werden könnten

Verwandte Beiträge

1 Kommentare

 
GN⁺ 5 시간 전
Kommentare auf Lobste.rs
  • Ich wünschte wirklich, der Capsicum-Versuch für Linux wäre nicht wegen NIH gestorben.
    Für Sandboxing von Desktop-Apps ist das ein deutlich besseres Modell als der ganze Flickenteppich aus Ansätzen, die man unter Linux aufgebaut hat, um Ähnliches zu erreichen: Der Launcher übergibt auf Basis der Metadaten die anfängliche Menge an Berechtigungen, also File Descriptors, die App kann auf nichts darüber hinaus zugreifen, und eine Powerbox stellt Berechtigungen zum Öffnen und Speichern weiterer Dateien bereit.
    • Das gesamte Container-Modell von Linux wirkt wie ein etwas zusammengeflicktes Bündel unausgereifter Konzepte.
      Für Umgebungen, in denen irgendein gottgleicher Prozess Dienste orchestriert, etwa Kubernetes-Services, passt das meistens, auf dem Desktop aber nicht. Man möchte im Userspace in eine niedriger privilegierte cgroup/namespace wechseln, muss dafür aber Rituale wie einen Root-Daemon oder setuid durchlaufen, was am Ende Risiken durch Privilege Escalation mit sich bringt.
    • Theoretisch sollten die großen Sandboxing-Tools für den Linux-Desktop wie Flatpak mit SCM_RIGHTS + Wayland + D-Bus als Grundbausteinen genau so funktionieren.
      Wenn man die Augen zusammenkneift, kann man die Umrisse eines sicheren Desktops erkennen.
      In der Praxis sind die Implementierungen aber insgesamt entweder zu großzügig, zu unflexibel oder halb kaputt. Es scheint niemandem End-to-End-Sicherheit auf dem Desktop so wichtig zu sein wie die Absicherung von Server-Workloads. Deshalb funktionieren gVisor und Firecracker gut, während Flatpak es schwer hat, selbst eine einfache Gtk+-App ohne kaputte Schriftarten auszuführen, und jeder Wayland-Compositor die Hälfte der Grundlage für einen vertrauenswürdigen Desktop neu implementieren muss.
      Das ist umso peinlicher, wenn man bedenkt, dass Android seine Rolle als ausreichend gehärtete Linux-Distribution zum Ausführen nicht vertrauenswürdigen Codes ziemlich gut erfüllt hat und iOS sowie macOS gezeigt haben, dass Sandboxing für nutzerseitige Apps durchaus angenehm benutzbar sein kann. Man sollte einfach machen, was sie machen. Warum zum Teufel liest irgendetwas im Window Manager /proc/{pid}/cmdline?
  • Es sieht nicht gut aus, dass es nach dem Scheitern eines Upstream-Patches zu einer öffentlichen Offenlegung kam.
    Das ist ausdrücklich keine Kritik an dem Forscher.
  • Ich weiß nicht, ob der an Upstream geschickte Issue-Report auch so war, aber es war ziemlich schwer, ihm zu folgen.
    Wenn man mit den Interna von KDE oder Flatpak vertrauter ist, hätte man ihn vermutlich viel besser verstanden.