XFCE4-Screensaver <= 4.20.2 Login Bypass Vulnerability
Dear Sir or Madam, We are Murat Altindis and Maria Kessler, and we are penetration testers at AWARE7 GmbH in Germany. On a computer running the Qubes OS operating system, we noticed that under certain circumstances it is possible to bypass the XFCE4 Screensaver. To do this, an external monitor must be used as the main screen via HDMI so that the login window appears on this monitor after locking. If you wait until this monitor receives the shutdown signal, or alternatively, while the computer is locked, unplug the HDMI cable and plug it back in after the "No HDMI Signal" message appears, there is a small window of time where keyboard input can bypass the screensaver. This period is so long that it was possible to use a stick that supports DuckyScript to emulate the terminal key and then the command `xfce4-screensaver-command --exit` on Qubes OS. This allows you to completely turn off the screensaver and gain control of the device without entering the password of the locked device. We took this as an opportunity to set up a new device with the Kali Linux operating system, which has Xfce screensaver 4.20.2 installed by default, and were able to reproduce the steps on the device, with the difference that in this case the time window is too short to be able to execute this exploit in one go. It is necessary to perform these steps in several attempts, which is also possible because this vulnerability occurs not only when the computer is locked for the first time, but every time the external main monitor loses the HDMI signal and then attempts to reconnect. My colleague and I then looked at the source code of the xfce4 screensaver at https://github.com/xfce-mirror/xfce4-screensaver to find the cause and to make sure that the problem could be solved from the XFCE side. We believe we have found a hotfix for this vulnerability, which completely blocks keyboard input while a new window is being created and resets the login window at the end. Below, you will find our hotfix for this issue. Nuke all input at (https://github.com/xfce-mirror/xfce4-screensaver/blob/master/src/gs-manager.c): ``` static void recreate_windows (GSManager *manager) { GdkDisplay *display = gdk_display_get_default (); guint n_monitors = gdk_display_get_n_monitors (display); gs_debug ("Reconfiguring monitors, recreating windows"); #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) { /* ---- START OF HOTFIX ---- */ gs_debug("Start of hotfix"); gdk_x11_display_error_trap_push(display); XSetInputFocus(GDK_DISPLAY_XDISPLAY(display), None, RevertToNone, CurrentTime ); /* ---- END OF HOTFIX ---- */ gs_grab_move_to_window (manager->priv->grab, gtk_widget_get_window (manager->priv->overlay), display, FALSE, FALSE); } #endif ... } ``` Regrab Input and focus parent at (https://github.com/xfce-mirror/xfce4-screensaver/blob/master/src/gs-manager.c): ``` static gboolean window_map_event_cb (GSWindow *window, GdkEvent *event, GSManager *manager) { gs_debug ("Handling window map_event event"); #ifdef ENABLE_X11 if (manager->priv->grab != NULL) { manager_maybe_grab_window (manager, window); /* ---- START OF HOTFIX ---- */ gs_debug("Start of Hotfix: Restoring focus"); 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_push(display); /* ---- END OF HOTFIX ---- */ } #endif ... } ``` We would like to note that the system we used as a target is a newly set up Kali Linux instance with default settings, which has xfce-screensaver 4.20.2 installed by default. We were able to reproduce the same vulnerability on devices running Xfce Screensaver versions 4.16.x and 4.18.x. We would assess the criticality of the vulnerability as follows: CVSS:3.1/AV:P/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L (4.1) CVSS:4.0/AV:P/AC:L/AT:N/PR:N/UI:P/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N (2.4) We are available to answer any questions you may have at any time at the email address mna@a7.de. Best regards, Murat Altindis (AWARE7 GmbH) and Maria Kessler (AWARE7 GmbH)
issue