XFCE-Screensaver-Schwachstelle: Sperrbildschirm-Bypass per Monitorwechsel

Kurzantwort: Der xfce4-screensaver weist eine Schwachstelle auf, die den Sperrbildschirm beim Monitorwechsel oder beim An- und Abstecken eines HDMI-Kabels umgeht. Ursache ist ein Zeitfenster zwischen XUngrabServer und dem neuen Fenster-Grab, in dem X11 Tastatureingaben an Hintergrundprozesse weiterreicht. Unser Fix erzwingt einen expliziten Fokus-Reset per XSetInputFocus vor dem Neu-Grab und wurde in Merge Request #60 des xfce4-screensaver eingereicht.

Welche Systeme sind vom XFCE-Screensaver-Bypass betroffen?

Betroffen sind alle Linux-Systeme mit xfce4-screensaver als Sperrbildschirm, bestätigt bis zur Version 4.20.2. In unserer Analyse reproduzierten wir das Verhalten auf Qubes OS und auf einer Kali-Linux-Standardinstallation. Da die Ursache in der Interaktion mit dem X11-Fenstermanager liegt, sind weitere XFCE-basierte Distributionen wie Xubuntu, Manjaro XFCE und Linux Mint XFCE mit hoher Wahrscheinlichkeit ebenfalls angreifbar.

Aufgefallen ist das Problem zuerst unter Qubes OS. Dessen Sicherheitsmodell stützt sich auf strikte Isolation: Anwendungen laufen in separaten virtuellen Maschinen, Eingaben werden über sys-usb oder sys-net an die AppVM weitergereicht.

Diese zusätzlichen Hops vergrößern das Zeitfenster, in dem Tastatureingaben am Sperrbildschirm vorbeilaufen. In unserem Fall machten sie die Schwachstelle überhaupt erst reproduzierbar. Das Sicherheitsdesign von Qubes OS ist also nicht die Ursache — es ist das Mikroskop, unter dem der Defekt sichtbar wurde.

Der Screensaver ist dabei eine besonders sensible Komponente. Er entscheidet, ob eine gesperrte Sitzung ohne Passwort nutzbar ist. Versagt er, greifen die anderen Schutzmechanismen in der Regel nicht mehr.

Wie funktioniert die Schwachstelle technisch?

Der Bypass basiert auf einer Race Condition zwischen dem Freigeben und dem Neuanfordern eines X11-Server-Grabs. X11 verarbeitet Tastatur- und Mausereignisse zentral über den X-Server; ein Screenlocker beansprucht diese Eingaben exklusiv, indem er einen Server-Grab setzt. Wird der Grab freigegeben, bevor der neue Grab etabliert ist, landen Eingaben in dem Fenster, das gerade Fokus hat.

Beim Wechsel eines Monitors oder beim Verlust des HDMI-Signals erstellt xfce4-screensaver das Login-Fenster neu. Dafür gibt er den alten Grab frei (XUngrabServer) und fordert einen neuen an, sobald das neue Fenster verfügbar ist.

Zwischen den beiden Operationen liegt, je nach System, ein Zeitfenster von etwa einigen hundert Millisekunden, in dem Tastatureingaben an Hintergrundprozesse durchgereicht werden. Wer ein Terminal oder einen Editor im Hintergrund offen hatte, schreibt in dieses Fenster hinein — ohne Authentifizierung.

Kritisch wird dieses Verhalten in Kombination mit Shortcuts. Wer einen Tastenbefehl an xfce4-screensaver-command --exit gebunden hat oder ein Terminal per CTRL+ALT+T öffnen lässt, kann den Screenlock gezielt beenden. Das ist der eigentliche Angriffsvektor.

Wie haben wir den Bypass entdeckt?

Entdeckt haben wir das Verhalten bei der Ersteinrichtung eines neuen Qubes-OS-Systems — nicht durch gezielte Suche, sondern durch Zufall. Nach einer etwa 15-minütigen Pause und dem Entsperren des Systems standen in einem Browser-Textfeld zufällig wirkende Zeichen. Das waren Tasten, die wir zum Aufwecken des Systems gedrückt hatten und die offenbar nicht der Sperrbildschirm, sondern der im Hintergrund laufende Browser verarbeitet hatte.

Die Ursache ließ sich eingrenzen: Das Verhalten trat reproduzierbar auf, sobald ein externer Monitor im gesperrten Zustand das HDMI-Signal verlor und das System den Monitor nach der Eingabe neu initialisierte. Dasselbe Ergebnis ließ sich erzeugen, indem wir das HDMI-Kabel im Sperrzustand aus- und wieder einsteckten.

In unserer Pentest-Praxis sehen wir häufig, dass Screenlocker die letzte Verteidigungslinie sind, wenn physischer Zugriff droht. Ein Bypass über eine triviale Hardware-Aktion wie das Umstecken eines Kabels senkt die Angriffsschwelle deutlich — insbesondere in Coworking-Umgebungen oder Konferenzräumen.

„Dass ein Tastendruck auf einem gesperrten System überhaupt im Browser landet, war der Moment, in dem klar war: das ist keine Kosmetik. Die Kombination aus Monitor-Reinitialisierung und X11-Grab-Freigabe öffnet ein ausreichend großes Fenster, um mit einem LilyGo T-Dongle S3 reproduzierbar in eine ungesperrte Shell zu tippen."

— Murat Altindis, Offensive Security Consultant, AWARE7 GmbH

Wie lässt sich der Exploit reproduzieren?

Manueller Proof of Concept

Die einfachste Form der Bestätigung ist ein benutzerdefinierter Shortcut, zum Beispiel F7, der ein Terminal öffnet und den Screensaver beendet:

xfce4-terminal -x bash -c "xfce4-screensaver-command --exit"

Im Zeitfenster nach dem Monitor-Reset tippt das System den Shortcut nicht in den Screenlock, sondern in die Hintergrund-Anwendung. Das Terminal startet, der Befehl wird ausgeführt, der Screenlock wird ohne Passwort beendet.

Automatisierung mit LilyGo T-Dongle S3

Auf Kali Linux mit dem aktuellen xfce4-screensaver 4.20.2 war das Zeitfenster für manuelle Eingaben zu kurz. Für eine zuverlässige Reproduktion haben wir einen LilyGo T-Dongle S3 eingesetzt — ein ESP32-S3-basiertes Gerät, das vom System als USB-Tastatur erkannt wird. Die Firmware stammt aus dem Open-Source-Projekt USBArmyKnife, das DuckyScript direkt auf dem ESP32-S3 ausführt.

Das Payload ist minimal:

KEYBOARD_LAYOUT win_de-DE
CTRL ALT T
DELAY 50
STRING xfce4-screensaver-command --exit
ENTER

Ablauf: Das deutsche Tastaturlayout stellt sicher, dass Sonderzeichen korrekt übertragen werden. CTRL ALT T öffnet ein Terminal, 50 Millisekunden Pause geben der Shell Zeit zum Laden, die STRING-Zeile tippt den Befehl Zeichen für Zeichen, ENTER führt ihn aus. Das richtige Timing ergibt sich per Brute-Force: Wir wiederholten die Sequenz, bis sie das Zeitfenster traf.

Wo liegt die Ursache im Source-Code?

Für die Root-Cause-Analyse haben wir den xfce4-screensaver aus dem offiziellen GitLab-Repository geklont, selbst kompiliert und den installierten Screensaver durch unsere Debug-Version ersetzt. Über zusätzliche Log-Zeilen mit Millisekunden-Zeitstempeln konnten wir die Code-Pfade mit dem Auftreten des Leaks korrelieren.

Die Schlüsselstelle ist folgender Aufruf beim Release des Server-Grabs:

gs_debug ("*** Releasing X server grab");
gdk_x11_display_ungrab (display);
gdk_display_flush (display);

Der Leak trat zeitlich versetzt, etwa 500 bis 600 Millisekunden nach diesem Aufruf, auf. Ein bereits vorhandener Kommentar im Code zeigte, dass das grundsätzliche Risiko den Entwicklern bewusst war — offenbar ohne dass das Ausmaß eines echten Bypasses bekannt war:

#ifdef ENABLE_X11
    /*
     * It doesn't prevent all leaks, but it's better than nothing. Preventing all leaks would
     * probably require keeping the grab on the overlay permanently and passing events to the
     * screensaver windows, which seems overly complicated given what's at stake.
     */
    if (manager->priv->grab != NULL) {
        gs_grab_move_to_window (manager->priv->grab,
                                gtk_widget_get_window (manager->priv->overlay),
                                display, FALSE, FALSE);
    }
#endif

Die eigentliche Ursache ist der Aufruf von gdk_x11_display_ungrab, der in der GDK-Bibliothek letztlich XUngrabServer der X11-Bibliothek aufruft:

void
gdk_x11_display_ungrab (GdkDisplay *display)
{
  GdkX11Display *display_x11;

  g_return_if_fail (GDK_IS_DISPLAY (display));

  display_x11 = GDK_X11_DISPLAY (display);
  g_return_if_fail (display_x11->grab_count > 0);

  display_x11->grab_count--;
  if (display_x11->grab_count == 0)
    {
      XUngrabServer (display_x11->xdisplay);
      XFlush (display_x11->xdisplay);
    }
}

Zwischen XUngrabServer und dem Setzen des neuen Grabs hat X11 kein aktives Fenster für den Screenlock registriert. Eingaben gehen an das Fenster, das zuletzt Fokus hatte. Wir haben diese These durch eine modifizierte Screensaver-Version bestätigt: Eingaben im Bypass-Fenster wurden gar nicht erst vom Screensaver erfasst, sondern direkt von X11 an Hintergrundprozesse durchgereicht.

Welcher Fix schließt die Lücke?

Der Fix setzt am Fokus an, nicht am Grab-Verhalten. Vor dem Neu-Grab entziehen wir allen Fenstern den Fokus und setzen ihn anschließend explizit auf das neue Login-Fenster:

GdkDisplay *display = gs_window_get_display (window);
GdkWindow *gdk_win = gs_window_get_gdk_window (window);

gdk_x11_display_error_trap_push (display);
XSetInputFocus (GDK_DISPLAY_XDISPLAY (display), GDK_WINDOW_XID (gdk_win), RevertToParent, CurrentTime);
gdk_x11_display_error_trap_pop_ignored (display);

Platziert haben wir das unmittelbar vor dem bestehenden Aufruf:

manager_maybe_grab_window (manager, window);

Im window_map_event_cb, das beim Erstellen eines neuen Fensters aufgerufen wird. Theoretisch wäre es sauberer gewesen, den Fokus erst nach dem neuen Grab zu setzen — in unseren Tests verhinderte das aber zuverlässig, dass sich Nutzer anschließend anmelden konnten. Der vorgezogene Fokus-Reset ist deshalb ein bewusster Kompromiss.

Der Fix wurde am 11. März 2026 als Merge Request #60 im xfce4-screensaver-Projekt eingereicht und liegt zur Übernahme vor.

Wie hoch ist das Restrisiko nach dem Fix?

Der Fix verhindert zuverlässig, dass Tastatureingaben in Hintergrund-Textfelder getippt werden — das erforderte einen Fokus, der jetzt fehlt. Hotkeys lassen sich damit nicht abfangen, weil sie keinen Fensterfokus benötigen. Wer xfce4-screensaver-command --exit oder vergleichbar kritische Aktionen an globale Shortcuts gebunden hat, ist weiter angreifbar.

In einer Standardkonfiguration ohne sicherheitskritische Custom-Shortcuts ist das Restrisiko gering. Der strukturell saubere Weg wäre, gar nicht mehr mit Grabs zu arbeiten, sondern das Login-Fenster beim Monitorwechsel zu verschieben statt neu zu erstellen. Das würde eine grundlegende Umgestaltung des xfce4-screensaver bedeuten und steht aktuell nicht zur Diskussion.

Praxis-Empfehlung: Prüfen Sie Ihre XFCE-Keybindings auf Befehle, die den Screenlock beenden, Shells öffnen oder privilegierte Skripte starten. Solche Shortcuts bleiben ein Angriffsvektor, auch mit dem Fix.

Fazit: Ist der xfce4-screensaver weiter nutzbar?

Unser erster Reflex war, vom Einsatz des xfce4-screensaver abzuraten. Nach dem Austausch mit den Entwicklern von xfce4-screensaver und Qubes OS sehen wir es differenzierter. Keine Screenlocker-Implementierung auf X11 ist gegen diese Klasse von Timing-Problemen immun — vergleichbare Lücken sind in der Vergangenheit bei anderen Lockern aufgetreten.

Entscheidend ist die Reaktionsgeschwindigkeit der Maintainer. Unser Fix wurde konstruktiv am Merge Request diskutiert; der Austausch mit den Entwicklern verlief zügig und inhaltlich fundiert. Das ist ein positives Signal für das Projekt.

Wer maximale Isolation braucht, sollte trotzdem prüfen, ob der Umstieg auf Wayland mittelfristig möglich ist. Wayland löst die grab-basierte Logik durch ein kompositorzentriertes Modell, in dem der Screenlock Teil des Compositors ist und Fokus-Wechsel nicht in diesem Zeitfenster laufen. Auf X11 bleibt die Empfehlung pragmatisch: aktuelle Version einspielen, Hotkeys auditieren, Bequemlichkeit nicht über Sicherheit stellen.

FAQ: Häufige Fragen zum XFCE-Screensaver-Bypass

Welche xfce4-screensaver-Versionen sind betroffen?

Bestätigt ist die Schwachstelle bis einschließlich xfce4-screensaver 4.20.2, die zum Zeitpunkt unserer Analyse die aktuelle Release war. Ältere 4.x-Versionen teilen die grundlegende Grab-Logik und sind mit hoher Wahrscheinlichkeit ebenfalls betroffen. Ob der Fix aus Merge Request #60 in eine stabile Release übernommen wurde, prüfen Sie am besten direkt im xfce4-screensaver-Repository.

Gilt die Schwachstelle auch für andere X11-Screenlocker?

Die konkrete Code-Stelle ist XFCE-spezifisch, das zugrundeliegende Problem aber ein generisches X11-Muster: eine Race Condition zwischen XUngrabServer und dem neuen Grab. Historisch zeigen xscreensaver, slock und i3lock unterschiedliche Varianten ähnlicher Probleme. Eine belastbare Aussage zu einem konkreten Locker setzt eine eigene Code-Analyse voraus.

Wie kann ich prüfen, ob mein System verwundbar ist?

Setzen Sie einen Shortcut wie F7 auf den Befehl xfce4-terminal -x bash -c "xfce4-screensaver-command --exit", sperren Sie den Bildschirm, stecken Sie das HDMI-Kabel kurz ab und wieder ein und drücken Sie die Shortcut-Taste. Öffnet sich der Sperrbildschirm ohne Passwort, ist das System angreifbar. Führen Sie diesen Test nur auf einem Gerät durch, das Sie kontrollieren.

Wurde eine CVE-ID vergeben?

Zum Zeitpunkt der Veröffentlichung dieses Beitrags liegt uns keine CVE-ID vor. Wir haben den Fix direkt mit den Maintainern des xfce4-screensaver und des Qubes-OS-Projekts koordiniert und nicht über die klassische CVE-Disclosure-Kette eingereicht, weil der Patch bereits vorlag. Sollte eine CVE-ID nachträglich durch MITRE oder einen CNA wie Canonical oder Red Hat zugeteilt werden, aktualisieren wir diesen Beitrag und ergänzen die ID hier.

Welche Alternativen gibt es zum xfce4-screensaver?

Auf X11 sind xscreensaver, slock und physlock etablierte Alternativen, jede mit eigenem Trade-off zwischen Integration, Feature-Umfang und Angriffsfläche. Die strukturell sicherere Variante ist der Umstieg auf Wayland-basierte Umgebungen wie GNOME auf Wayland oder KDE Plasma auf Wayland, in denen Screenlocks Teil des Compositors sind.

Nächste Schritte

Sie vermuten eine vergleichbare Schwachstelle in Ihrer Infrastruktur? In unseren Pentests prüfen wir Endpoint-Hardening inklusive Screenlock-Verhalten, physischer Zugriffsszenarien und HID-Angriffe.

• Kostenlose Erstberatung vereinbaren
• Leistung: Penetrationstest
• Leistung: Red Teaming

Weiterführende Wiki-Artikel: Linux-Server-Härtung · Endpoint Security · Schwachstellenmanagement.

---

Hero-Bild mit KI-Unterstützung erstellt (Black Forest Labs Flux 1.1 Pro). Kennzeichnung gemäß EU AI Act Art. 50.