QSB-068: Disconnecting a video output can cause XScreenSaver t | Qubes OS📢

QSB-068: Disconnecting a video output can cause XScreenSaver to crash
https://www.qubes-os.org/news/2021/06/04/qsb-068/

We have just published Qubes Security Bulletin (QSB) 068:
Disconnecting a video output can cause XScreenSaver to crash.
The text of this QSB is reproduced below. This QSB and its accompanying
signatures will always be available in the Qubes Security Pack (qubes-secpack).

View QSB-068 in the qubes-secpack:

https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-068-2021.txt

Learn about the qubes-secpack, including how to obtain, verify, and read it:

https://www.qubes-os.org/security/pack/

View all past QSBs:

https://www.qubes-os.org/security/bulletins/



---===[ Qubes Security Bulletin 068 ]===---

2021-06-04


Disconnecting a video output can cause XScreenSaver to crash


User action required
=====================

Users must install the following specific packages in order to address
the issues discussed in this bulletin:

For Qubes 4.0, in dom0:
- xscreensaver 5.45-5

For Qubes 4.1, in dom0:
- xscreensaver 5.45-5

These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community. [1] Once available, the packages are to be installed
via the Qubes Update Tool or its command-line equivalents. [2]

After installing this update, the XScreenSaver daemon process must be
restarted in order for the changes to take effect. This can be done by
restarting dom0, logging out of dom0 then logging back in, or issuing
the following command in a dom0 terminal:

xscreensaver-command -exit; xscreensaver &


Summary
========

XScreenSaver is the default screen locker in dom0. It tracks which video
outputs are connected to the system in order to blank them properly. In
some specific hardware configurations, disconnecting an output can cause
XScreenSaver to crash, leaving the screen unlocked.

Impact
=======

On hardware configurations with more than 10 video outputs that can be
disconnected, an attacker with physical access to a screen-locked system
may be able to unlock it by physically disconnecting one or more
outputs, bypassing standard screen lock authentication.

Details
========

On X11, screen locking and blanking is done by creating a window that
obscures the whole screen, which is a standard practice. In
XScreenSaver, each such window is assigned a specific property. When a
video output is disconnected, its corresponding blanking window is
destroyed, and its XScreenSaver-specific property is removed so that it
will not be used by `xscreensaver-command` anymore. This is handled by
the `update_screen_layout()` function in the `driver/screens.c` file:

985 /* Synchronize the contents of si->ssi to the current state of the monitors.
986 Doesn't change anything if nothing has changed; otherwise, alters and
987 reuses existing saver_screen_info structs as much as possible.
988 Returns True if anything changed.
989 */
990 Bool
991 update_screen_layout (saver_info *si)
992 {
993 monitor **monitors = scan_monitors (si);
994 int count = 0;
995 int good_count = 0;
...
1009 while (monitors[count])
1010 {
1011 if (monitors[count]->sanity == S_SANE)
1012 good_count++;
1013 count++;
1014 }
1015
1016 if (si->ssi_count == 0)
1017 {
1018 si->ssi_count = 10;
1019 si->screens = (saver_screen_info *)
1020 calloc (sizeof(*si->screens), si->ssi_count);
1021 }
1022
1023 if (si->ssi_count <= good_count)
1024 {
1025 si->ssi_count = good_count + 10;
1026 si->screens = (saver_screen_info *)
1027 realloc (si->screens, sizeof(*si->screens) * si->ssi_count);
1028 memset (si->screens + si->nscreens, 0,