We have just published Qubes Security Bulletin (QSB) 072: Inconsistent handling of the override-redirect flag. 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-072 in the qubes-secpack:
In addition, you may wish to:
- Get the qubes-secpack: https://www.qubes-os.org/security/pack/
- View all past QSBs: https://www.qubes-os.org/security/qsb/
---===[ Qubes Security Bulletin 072 ]===--- 2021-09-27 Inconsistent handling of the override-redirect flag 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: - qubes-gui-dom0 version 4.0.15 For Qubes 4.1, in dom0 and the template(s) of any GUI qube(s) : - qubes-gui-daemon version 4.1.16 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.  Once available, the packages are to be installed via the Qubes Update tool or its command-line equivalents.  The user session must be restarted afterward in order for the updates to take effect, e.g., by logging out then logging back in. Summary -------- An override-redirect flag in the X11 protocol tells the window manager not to manage a particular window. Windows with such flags do not get their frames or title bars from the window manger, nor does the window manager determine their positions. This feature is used for application menus, tooltips, and similar accessory windows. Since the window manager ignores such windows, the GUI daemon imposes certain extra constraints on them, such as drawing thin colored frames. Unfortunately, there are several cases in which the window manager and GUI daemon do not agree on the override-redirect flag state, leading to neither of them imposing the appropriate constraints. Impact ------- Normally, every window in Qubes OS has an unspoofable colored frame, except for those belonging to dom0 or a GUI qube.  The flaws described in this bulletin allow a malicious qube to create a window that has no such colored frame. Such a window might be made to appear as though it belongs to a different qube. For example, a malicious qube with an untrusted color label might draw a passphrase prompt window. Then, in order to induce the user to enter a valuable passphrase into this window, the malicious qube might draw a fake frame in a different color (more trusted than its own) along the inside edge of the window. Since the window has no externally-imposed colored frame of its own, the user might be deceived into accepting the fake internally-drawn frame as a reliable indicator of the window's trust level or origin. Such windows are also capable of bypassing limits normally imposed on windows with the override-redirect flag. For example, such windows are capable of covering desktop environment panels, potentially preventing users from interacting with certain parts of the system or displaying fake interface elements. Since such windows also lack colored frames, they could be made to appear as though they belong to dom0 or a GUI qube in an attempt to deceive users into believing that they are interacting with trusted parts of the system. Discussion ----------- There were several cases in which the GUI daemon's view of the override-redirect flag did not match the window manager's expectations: 1. Using an MSG_CONFIGURE GUI protocol  command to change the override-redirect flag of a window that has already been mapped (i.e., made visible). In this case, the GUI daemon saved the new state of the flag (and thus stopped applying its own constraints), but it had not yet sent this flag to the X server. 2. Using an MSG_MAP GUI protocol  command to change the override-redirect flag of a window that has already been mapped. In this case, the attribute was updated in the X server, but the window manager did not pick up the change, since the window was already mapped. 3. The override-redirect protection feature, which prevents a window from covering more than 90% of the screen if it has the override-redirect flag, suffered from the same problem described in the first point. 4. It was unclear how docked windows (aka "tray icons") should interact with the override-redirect flag. Neither the XEmbed Protocol Specification  nor the System Tray Protocol Specification  defines how they should interact. 5. Docking a window passes control over mapping and unmapping the window to the embedder (the application that "holds" the docked windows). The implications of this behavior are unclear, and we cannot rule out the possibility that this could be abused in some way. 6. There are two things that draw externally-imposed colored frames in Qubes OS: the window manager and the GUI daemon. The GUI daemon draws colored frames around windows with the override-redirect flag and docked windows (aka "tray icons"), while the window manager draws all other colored frames, e.g., for "normal" windows. (The window manager also controls the title bar, which is another type of trusted window decoration.) Any window, including a docked window, can have a "child" window, which is a separate window embedded in the parent window. Children do not have the override-redirect flag, even when their parents do. Children also do not have colored frames externally imposed by the GUI daemon, even when their parents do. Therefore, it is possible for a child window to extend its position to cover the parent window's GUI-daemon-imposed colored frame, then draw a fake frame in a different color directly on top of the parent window's colored frame. A malicious qube could exploit this in order to make it appear that a window belongs to a higher trust level than its actual trust level. Likewise, since the GUI daemon also forces coloring on docked windows by default, a child window could cover its parent's docked window in order to draw a "tray icon" in a different color. To fix these problems, the GUI daemon will no longer accept changes to the override-redirect flag in the cases described above. Instead, the override-redirect flag can now be changed in only two cases: - When the window is not yet visible (either as a normal window or as a tray icon) and has no children - When override-redirect protection forcefully clears the flag, in which case the window is unmapped, the flag is cleared, and the window is mapped again Moreover, in order to avoid confusing the embedder and the GUI daemon, windows that are already mapped or have children will now be prevented from being docked. Credits -------- This issue was discovered by Demi Marie Obenour. Notes ------  In Qubes 4.1, certain GUI functions historically served by dom0 can be delegated to separate template-based "GUI qubes." A single Qubes 4.1 system can have multiple GUI qubes.  https://www.qubes-os.org/doc/testing/  https://www.qubes-os.org/doc/how-to-update/  https://www.qubes-os.org/doc/gui/  https://specifications.freedesktop.org/xembed-spec/xembed-spec-latest.html  https://specifications.freedesktop.org/systemtray-spec/systemtray-spec-latest.html -- The Qubes Security Team https://www.qubes-os.org/security/