[qubes-users] QSB-073: Race condition when setting override-redirect flag

[Andrew David Wong]

Dear Qubes Community,

We have just published Qubes Security Bulletin (QSB) 073: Race condition
when setting 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-073 in the qubes-secpack:



In addition, you may wish to:

- Get the qubes-secpack: 
- View all past QSBs: 
- View the XSA Tracker: 

```

 ---===[ Qubes Security Bulletin 073 ]===---

  2021-10-15

 Race condition when setting 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.17

  For Qubes 4.1, in dom0 and the template(s) of any GUI qube(s) [1]:
  - qubes-gui-daemon version 4.1.18

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. [2] Once available, the packages are to be installed
via the Qubes Update tool or its command-line equivalents. [3]

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.

Unfortunately, some window managers get confused if the
override-redirect flag is set shortly before making the window visible.
When that happens, the window manager may try to move or resize the
window without respecting any size and position constraints imposed by
the GUI daemon. Normally, every window move and resize action requested
by the VM is validated by the GUI daemon. However, if the action is
initiated by the window manager, it doesn't require the GUI daemon's
validation.


Impact
---

A malicious application may try to hide its unspoofable colored frame
off-screen. Hiding all four sides is prevented by another constraint
(forbidding a override-redirect window from covering more than 90% of
the screen), but hiding some sides is possible. The issue is known to
affect XFCE and KDE. Other desktop environments may also be affected.


Discussion
---

This is yet another corner case in handling the override-redirect flag.
In the long term, we will try to eliminate use of this flag completely.
As an immediate fix, we are adding additional validation of constraints
placed on windows with the override-redirect flag. This validation is
done whenever a window is moved or resized, regardless of what initiated
the action. If an illegal size or position is detected, the GUI daemon
will try to resize or move the window back to a legal size and position.
While this is a reactive solution (in the sense that it allows windows
to enter illegal states before correcting them), it will cover several
more cases, including the case in which another application resizes a
window behind the GUI daemon's back (which is the case being reported in
this QSB). Moreover, this solution serves as an additional safety check
in case the GUI daemon itself misses any other edge cases.


Credits


This issue was discovered by Demi Marie Obenour.


Notes
--

[1] 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.
[2] https://www.qubes-os.org/doc/testing/
[3] https://www.qubes-os.org/doc/how-to-update/

--
The Qubes Security Team
https://www.qubes-os.org/security/

```

This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2021/10/15/qsb-073/

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/02f229b0-82bc-762b-1411-4f783d098467%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature

[qubes-users] Re: Printer recommendation / scanner implications?

[Jean-Philippe Ouellet]

On Thu, Oct 14, 2021 at 3:11 PM Jean-Philippe Ouellet  wrote:
> As for firmware security: I assume all printers are probably
> vulnerable (and/or backdoored?) beyond any hope of being reasonable,
> and would like to put a simple trusted device in front to force all
> incoming data to be printed to go through something like the Qubes
> trusted PDF converter, to sanitize whatever fun PDF / postscript /
> whatever exploits might otherwise reach the printer.

This, naturally, implies that I consider wireless connectivity to be
an anti-feature, in that it represents an opportunity to bypass any
trusted document-structure sanitizer / re-encoder / isolation box.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CABQWM_A9pTRpY0YR9A2aF%2Bpbn%3Dk3TFc2-w2%2BQ20Gwxp1cGMCMw%40mail.gmail.com.

[qubes-users] Printer recommendation / scanner implications?

[Jean-Philippe Ouellet]

Hi,

I figure someone on this list might have done some research from a
perspective sharing similar goals.

Does anyone have a recommendation for a reasonable printer?

My rough objectives are as follows:
1. "Well-supported by linux." In practice I imagine this means
speaking standard protocols, or needing some FOSS CUPS plugin packaged
in the usual repos. Essentially, as long as it's not some
windows/mac-only proprietary nonsense, or GUI-requiring linux blob,
then it's probably good enough.
2. Does not persist printed pages in internal storage, intentionally
or otherwise. No "re-print last page(s)" anti-feature, or similar. I
think ultimately a deliberately "stateless" printer is really what I
desire, but I'd be surprised if those exist beyond perhaps some very
old simple ones with non-network (think parallel port) interfaces and
non-updatable firmware that is somehow trustworthily write-protected.
(Which sounds great, tbh, I'm just not aware of any like that nor
where to get them besides maybe getting lucky in an auction.)
3. Has economical and shelf-stable consumable parts (ink, toner,
etc.). Probably means laser printer?
4. Doesn't take forever to print things and jam every other page.
Probably means laser printer?
5. Color would be nice, but optional.
6. Lack of "printer dots" [1], or similar (font-mutation steganography
[2], if that's a thing now?) would be nice. Do any such machines even
exist these days? (Besides firmware reversing & removal of said
"feature" yourself, I suppose...)
7. Minimizing contribution to aggregate demand for production of
eventual waste. DRM'd ink cartridges and similar are dumb, and as much
as I'd welcome the challenge to defeat them, I don't want to spend my
time doing that right now. An abundance of the actual printers on
2nd-hand markets would be nice, or, if new, something expected to be
reliable and last a long time to amortize the cost of its production.
I'd be perfectly happy with some model already 10 years old as long as
they're available, reliable, and the consumables for it are still
available and/or self-refillable.

As for firmware security: I assume all printers are probably
vulnerable (and/or backdoored?) beyond any hope of being reasonable,
and would like to put a simple trusted device in front to force all
incoming data to be printed to go through something like the Qubes
trusted PDF converter, to sanitize whatever fun PDF / postscript /
whatever exploits might otherwise reach the printer.

A scanner would be nice too. I haven't thought through all the
implications of whether having a discrete scanner & printer vs.
combined unit has a meaningful impact on my threat model. There's the
obvious implication that a compromise of one may steal data from or
exfiltrate data via the other, but then, would such a mechanism need
to be targeted to avoid obvious accidental detection? How might a
likely targeting activation mechanism work? I'm sure it might be
interesting from an attacker's perspective to have a built-in
side-channel between them, but hopefully network (/usb) isolation and
sanitizing input documents would break any likely print-job command &
control vectors besides those which would rely on image processing
(which feels less likely)? Unclear. Thoughts on this welcome too.

Regards,
Jean-Philippe

[1]: https://en.wikipedia.org/wiki/Machine_Identification_Code
[2]: http://www.cs.columbia.edu/~cxz/publications/fontcode.pdf

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CABQWM_AETmn3gqFZV2mNPnjevdtb2wY2HdW9ho7KKe7nH8KGAA%40mail.gmail.com.

Re: [qubes-users] Re: usb keyboard not working on debian 11 template

[unman]

On Wed, Oct 13, 2021 at 06:38:19PM +0200, haaber wrote:
> > Unman wrote:
> > qubes-input-proxy-sender is installed by default in the debian-11
> > template.
> > If you are using a minimal template, this is meant for advanced users,
> > but in any case, installation of qubes-input-proxy-sender is documented
> > at https://www.qubes-os.org/doc/templates/minimal/
> > 
> 
> Dear unman, do you suggest rather upgrading a debian-10-minimal to
> debian-11-minimal, or re-installing a fresh one? In the 2nd case, what
> is the preferred install command in dom0? I am a bit confused, since
> there is good old qubes-dom0-update, there is salt, maybe another one.
> Which is best/safest?   Cheers, Bernhard

Personally I will (usually) install a fresh template - there isnt as yet
a stable Debian-11 template for Qubes though.
I (usually) do this from salt, but there is the handy qvm-template
command in 4.1.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/YWhIloVirY9939Fs%40thirdeyesecurity.org.