About X.Org vulnerability and Qubes

[Sphere]

https://threatpost.com/x-org-flaw-allows-privilege-escalation-in-linux-systems/138624/

It is said that leveraging the vulnerability is possible from a remote SSH session. Say an attacker was able to successfully gain a remote SSH session in an untrusted VM, do you think it would be possible to gain full control through qubes' implementation of X.org?

I checked around and if I understand it right, qubes utilizes X.org in order to integrate the display of PVH VM applications to what the user can/must see.

Because of this, what's in my mind right now is that it's possible to leverage this vulnerability to gain full control but since I don't have an idea of the codes or how exactly qubes' implementation of X.org works, I would like to kindly ask for your thoughts about this matter.

Earlier I was about to remove setuid of Xorg but I thought it has a good chance of breaking my desktop environment altogether and that would be alot of trouble for me.

[pixel fairy]

you can always clone a template and try such changes.

Each vm runs its own X server, which is already distrusted by dom0, so the chain would have to include an attack that works over vchan.

Future versions of qubes might default to wayland instead of X11, only because fedora probably will, and there wont be any reason to change that. appvms will probably continue to use X for a long time.

[unman]

This is just another vulnerability - if you give someone else access to
your Qubes machine, local or remote, you've diminished your security.

In this particular case, each qube runs its own Xserver, which may be
vulnerable, but you've already given someone else access to that qube.
Would it be possible to leverage that for an attack on dom0? That would
require an exploit on qubes_gui and vchan, and *that* would be available
to the external user whether this exploit existed or not.

Of course, the long awaited GUI domain would help to mitigate attacks
against X, but it isn't here yet.

unman

[Ilpo Järvinen]

On Mon, 29 Oct 2018, Sphere wrote:

> https://threatpost.com/x-org-flaw-allows-privilege-escalation-in-linux-systems/138624/
>
> It is said that leveraging the vulnerability is possible from a remote
> SSH session. Say an attacker was able to successfully gain a remote SSH
> session in an untrusted VM, do you think it would be possible to gain
> full control through qubes' implementation of X.org?

This is a built-in assumption in Qubes OS design. That is, that VMs
may/will get compromized due to bugs like this...

> I checked around and if I understand it right, qubes utilizes X.org in
> order to integrate the display of PVH VM applications to what the user
> can/must see.
>
> Because of this, what's in my mind right now is that it's possible to
> leverage this vulnerability to gain full control but since I don't have
> an idea of the codes or how exactly qubes' implementation of X.org
> works, I would like to kindly ask for your thoughts about this matter.

...but it does not lead to dom0 or cross-VM compromize because of how the
GUI isolation works (the GUI isolation does not run over X.org but is
implemented using a very simple protocol based on memcpy from X.org
buffers).

> Earlier I was about to remove setuid of Xorg but I thought it has a good
> chance of breaking my desktop environment altogether and that would be
> alot of trouble for me.

If you're worried about the VMs themselves having being compromised, you
can backup everything and use the "paranoid restore" mode after a clean
reinstall of Qubes.


--
i.

[Sphere]

I apologize for the late reply everyone. Thank you for your all your thoughts about this matter. I had read the responses days ago but I ended up forgetting to respond and marking this as complete.

Your responses have added to my knowledge and ease with the Qubes OS. I am grateful for all this.