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. -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/alpine.DEB.2.20.1810300735590.21103%40whs-18.cs.helsinki.fi. For more options, visit https://groups.google.com/d/optout.
