[qubes-users] QSB-072: Inconsistent handling of the override-redirect flag

[Andrew David Wong]

Dear Qubes Community,

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: 
- View all past QSBs: 

```

 ---===[ 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) [1]:
  - 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. [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.

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. [1] 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 [4] 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 [4] 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 [5] nor the System Tray Protocol Specification [6]
   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 

[qubes-users] Installation on MacBook Pro

[Qubes User]

Hi,

I am trying to install Qubes on Macbook Pro(15,5) 2019 Model but I can't 
get past the boot screen. I burned an image using Etcher but when I try to 
boot my Mac, the screen goes blank and the system freezes. I don't see any 
errors whatsoever.

Any suggestions on how to troubleshoot and get it running will be greatly 
appreciated.


Best regards

-- 
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/255611f2-fb22-440e-a30f-b4934a20b0c3n%40googlegroups.com.

Re: [qubes-users] Networking issue after upgrading to Fedora-33

[mgla...@gmail.com]

On Monday, 27 September 2021 at 13:58:47 UTC+1 unman wrote:

> On Mon, Sep 27, 2021 at 02:35:34AM -0700, mgla...@gmail.com wrote: 
> > 
> > Hi everyone, 
> > 
> > I'm looking for some help as to how to diagnose some app-VM networking 
> > issues. I have 2 vms, both based on the same template with identical 
> > config, but one can reach the internet and the other cannot. 
> > 
> > Before upgrading: 
> > 2 standalone VMs based on Fedora-30. One with a bunch of dev tools 
> > installed, one relatively untouched. I had multiple VMs based on these 
> two 
> > templates. I also updated my sys-net and sys-firewall to Fedora-33 at 
> the 
> > same time. 
> > 
> > Upgrade: 
> > I upgraded to Fedora-33, and realised I could rationalise my VMs, so now 
> > every appVM is based off the same Fedora-33 template. 
> > 
> > The issue: 
> > Some of my migrated VMs are completely fine, others have no network. 
> > I _think_ it is the VMs that used to be based on my old "untouched" vm 
> that 
> > have the issue. 
> > 
> > VM1: 
> > No networking at all. 
> > 
> > VM2: 
> > Networking is completely fine, everything works as expected. 
> > 
> > Both VMs are based on the same Fedora-33 template, with the same 
> (default) 
> > sys-firewall Networking, both with the firewall configured to allow all 
> > outgoing internet connections 
> > 
> > *vm1$ ping google.com* 
> > ping: google.com: Name or service not known 
> > 
> > *vm1$ dig google.com* 
> > ; <<>> DiG 9.11.35-RedHat-9.11.35-1.fc33 <<>> google.com 
> > ;; global options: +cmd 
> > ;; connection timed out; no servers could be reached 
> > 
> > *vm1$ resolvectl dns* 
> > Global: 10.139.1.1 10.139.1.2 
> > Link 2 (eth0): 
> > 
> > 
> > *vm2$ resolvectl dns* 
> > Global: 10.139.1.1 10.139.1.2 
> > Link 2 (eth0): 
> > Link 3 (br-11bfb2cd10e9): 
> > Link 4 (docker0): 
> > Link 5 (br-cf58034d074b): 
> > Link 6 (br-f9686c41a7f5): 
> > 
> > So there's definitely something wrong, but I don't know enough about 
> > Linux/Qubes networking to work out what. 
> > 
> > Any pointers gratefully received. 
> > 
>
> There is something wrong, but there is nothing in the detail you have 
> provided that might explain it. 
> So: 
> Do you have any custom firewall rules set on vm1? (qvm-firewall vm1) 
> Can you ping the firewall from vm1, by IP address? 
> Can you access a host on the internet by IP address?(e.g https://9.9.9.9) 
> If you create a new qube from the template, does networking work as 
> expected? 
> If you change templates on vm1, does networking work? 
>

Yes, there are custom firewall rules, but the firewall is set to  "Allow 
all outgoing internet connections". Which should ignore all the rules?

Yes, I can happily ping sys-firewall's IP from both vm1 and vm2.

No, I can't access a host on the internet by IP
vm1$ curl https://9.9.9.9
curl: (7) Failed to connect to 9.9.9.9 port 443: No route to host

Yes, creating a new qube from the same template works fine - networking is 
exactly as expected.

No, changing templates on vm1 doesn't fix it (I thought it did when I tried 
a month or so ago, but I just gave up without really trying to get to the 
bottom of what's wrong. Either way, it doesn't work now)

Changing vm1's network from sys-firewall to sys-net doesn't fix it, either.

But this is interesting though. This is what I get when pinging the IP of 
sys-net (whilst networking is set to sys-firewall):
vm1$ ping 10.137.0.5
PING 10.137.0.5 (10.137.0.5) 56(84) bytes of data.
>From 10.137.0.6 icmp_seq=1 Packet filtered
>From 10.137.0.6 icmp_seq=2 Packet filtered
>From 10.137.0.6 icmp_seq=3 Packet filtered
[...]
3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2077ms

(0.5 is the IP of sys-net and 0.6 is sys-firewall)

So somehow when I ping sys-net I get a response from sys-firewall. Huh!?

This is what happens on my working VM:

vm2$ ping 10.137.0.5
PING 10.137.0.5 (10.137.0.5) 56(84) bytes of data.
64 bytes from 10.137.0.5: icmp_seq=1 ttl=63 time=0.286 ms
64 bytes from 10.137.0.5: icmp_seq=2 ttl=63 time=0.529 ms
64 bytes from 10.137.0.5: icmp_seq=3 ttl=63 time=0.551 ms



-- 
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/bdd741ec-f8c0-4747-b531-5f7a79a923abn%40googlegroups.com.

Re: [qubes-users] Networking issue after upgrading to Fedora-33

[unman]

On Mon, Sep 27, 2021 at 02:35:34AM -0700, mgla...@gmail.com wrote:
> 
> Hi everyone,
> 
> I'm looking for some help as to how to diagnose some app-VM networking 
> issues. I have 2 vms, both based on the same template with identical 
> config, but one can reach the internet and the other cannot.
> 
> Before upgrading:
> 2 standalone VMs based on Fedora-30. One with a bunch of dev tools 
> installed, one relatively untouched. I had multiple VMs based on these two 
> templates. I also updated my sys-net and sys-firewall to Fedora-33 at the 
> same time.
> 
> Upgrade:
> I upgraded to Fedora-33, and realised I could rationalise my VMs, so now 
> every appVM is based off the same Fedora-33 template.
> 
> The issue:
> Some of my migrated VMs are completely fine, others have no network. 
> I _think_ it is the VMs that used to be based on my old "untouched" vm that 
> have the issue. 
> 
> VM1:
> No networking at all.
> 
> VM2:
> Networking is completely fine, everything works as expected.
> 
> Both VMs are based on the same Fedora-33 template, with the same (default) 
> sys-firewall Networking, both with the firewall configured to allow all 
> outgoing internet connections
> 
> *vm1$ ping google.com*
> ping: google.com: Name or service not known
> 
> *vm1$ dig google.com*
> ; <<>> DiG 9.11.35-RedHat-9.11.35-1.fc33 <<>> google.com
> ;; global options: +cmd
> ;; connection timed out; no servers could be reached
> 
> *vm1$ resolvectl dns*
> Global: 10.139.1.1 10.139.1.2
> Link 2 (eth0):
> 
> 
> *vm2$ resolvectl dns*
> Global: 10.139.1.1 10.139.1.2
> Link 2 (eth0):
> Link 3 (br-11bfb2cd10e9):
> Link 4 (docker0):
> Link 5 (br-cf58034d074b):
> Link 6 (br-f9686c41a7f5):
> 
> So there's definitely something wrong, but I don't know enough about 
> Linux/Qubes networking to work out what.
> 
> Any pointers gratefully received.
> 

There is something wrong, but there is nothing in the detail you have
provided that might explain it.
So:
Do you have any custom firewall rules set on vm1? (qvm-firewall vm1)
Can you ping the firewall from vm1, by IP address?
Can you access a host on the internet by IP address?(e.g https://9.9.9.9)
If you create a new qube from the template, does networking work as
expected?
If you change templates on vm1, does networking work?

-- 
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/YVHABAtgLCNk14le%40thirdeyesecurity.org.

[qubes-users] Networking issue after upgrading to Fedora-33

[mgla...@gmail.com]

Hi everyone,

I'm looking for some help as to how to diagnose some app-VM networking 
issues. I have 2 vms, both based on the same template with identical 
config, but one can reach the internet and the other cannot.

Before upgrading:
2 standalone VMs based on Fedora-30. One with a bunch of dev tools 
installed, one relatively untouched. I had multiple VMs based on these two 
templates. I also updated my sys-net and sys-firewall to Fedora-33 at the 
same time.

Upgrade:
I upgraded to Fedora-33, and realised I could rationalise my VMs, so now 
every appVM is based off the same Fedora-33 template.

The issue:
Some of my migrated VMs are completely fine, others have no network. 
I _think_ it is the VMs that used to be based on my old "untouched" vm that 
have the issue. 

VM1:
No networking at all.

VM2:
Networking is completely fine, everything works as expected.

Both VMs are based on the same Fedora-33 template, with the same (default) 
sys-firewall Networking, both with the firewall configured to allow all 
outgoing internet connections

*vm1$ ping google.com*
ping: google.com: Name or service not known

*vm1$ dig google.com*
; <<>> DiG 9.11.35-RedHat-9.11.35-1.fc33 <<>> google.com
;; global options: +cmd
;; connection timed out; no servers could be reached

*vm1$ resolvectl dns*
Global: 10.139.1.1 10.139.1.2
Link 2 (eth0):


*vm2$ resolvectl dns*
Global: 10.139.1.1 10.139.1.2
Link 2 (eth0):
Link 3 (br-11bfb2cd10e9):
Link 4 (docker0):
Link 5 (br-cf58034d074b):
Link 6 (br-f9686c41a7f5):

So there's definitely something wrong, but I don't know enough about 
Linux/Qubes networking to work out what.

Any pointers gratefully received.


-- 
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/94fb9c33-c37f-4181-acb6-25478e0ea46en%40googlegroups.com.