It says that it shows:
English is not my first language, but how it is written it is clear that the cause is already compromised dom0, and the consequence is easy full control of it? So, how dom0 was compromised?
Isn’t Qubes all about that once in dom0, nothing else matters?
From the comments on that video, the author tells us :
“Hi Pete, this video is not about remote compromise, is about remote control. It just shows that there’s no Dom0 isolation at all.”
Now that would lead to a good investigation, provided the author would be around to explain.
Regards.
Without implementation details, these aren’t very helpful.
I’m skeptical there’s anything here that breaks compartmentalization.
B
That’s why I posted the link to the channel, perhaps someone here might be more knowledgeable than me about the subject.
I’m very interested into that though.
Regards.
The author is writing about dom0 is not isolated at all. I have never learned that dom0 is isolated, but VMs. Also, dom0 ultimately relies on Xen (the only black color in the concept diagram). I clearly remember Joanna writing about this that they had to choose some platform if they don’t want to create their own - and they didn’t want. So if there was a Xen bug then “the game is over”.
That explains a lot. What other options are available ? Nova ?
https://genode.org/documentation/platforms/nova
https://genode.org/documentation/general-overview/index
I have never learned that dom0 is isolated
Of course dom0 is isolated.
That explains a lot.
What exactly does that explain? Be specific.
Nova ?
The developers of Qubes and Xen take security seriously. Perhaps you would like to tell us about the bugs in Xen and Qubes?
Curiously, why do you think one of the Qubes developers marked the above so-called “security hacks” as invalid. Thoughts?
Furthermore, while in theory dom0 is isolated from the outside world, some graphical devices (e.g. displays connected via HDMI or DVI) offer two-way communication, which threatens this isolation and makes it harder to maintain. If a malicious device (rather than the user’s trusted monitor) were to be connected to one of these ports, it could inject data that could be processed inside of dom0. As long as graphical devices are in dom0, they also cannot be safely proxied to other domains. This is because the various solutions to multiplexing access to the GPU at the GPU/driver level (which would expose the “full” GPU to a VM) are orders of magnitude more complex than running display drivers in just one place. We consider this added complexity too risky to put it in dom0. Errors in the drivers could expose dom0 to an attack, and attacks on dom0 are the biggest threat to the Qubes security model.
This is what I meant…
So far:
a) three of the videos I saw appeared to be “starting with VM 1 is compromised already, I can make unexpected or bad things happen in VM 1.” Well…yes, that is true!
b) one of the videos I saw appeared to be “starting with dom0 is compromised already, I can control dom0 remotely.” Well…yes, that is true!
How did they get compromised? It is not stated.
In particular, I already use one of these “hacks” personally as part of a workflow: I have one standalone VM where I have utilize a script to replace the QubesIncoming directory with a link that points to remote/external storage, which is similar to the “hack” which points elsewhere on the VM’s filesystem. It’s stated that this needs to be “fixed”, but no, it does not!
And on this topic…
Anyway…I interact with dom0, with my hands, ears and eyes and sometimes more (voice…when I’m mad), it is my machine after all.
So…dom0 is not 100% isolated, otherwise it would be useless: it has display ports (traditionally one-way…but mission creep has started giving some two-way features); it has PS2 keyboard and mouse; it has storage devices; etc.
Qubes is about mitigation and control over exposure.
To mitigate dom0 and/or system exposure: IOMMU is configured for protection from domUs and some hardware exploits; device disaggregation and disabling of PCIe hotplug are all used in Qubes to move some of the “more dangerous” dom0 connections out of reach of straightforward exploits. Etc.
In addition, if a machine is provided with higher quality bios/firmware, users can disable certain connections from their bios/firmware (e.g. webcam, firewire, thunderbolt, etc.) which also reduces dom0 exposure even before boot.
B
My apologies. I must admit to being a bit annoyed by this thread. The OP posted the same thing for Qubes devs and it was dismissed as invalid. Then he does the same thing on this forum. He didn’t make any effort to explain or discuss anything at all about the alleged “hacks”. And then with very little discussion about the claims, he apparently draws the conclusion that dom0 is leaking, Xen is compromised and Qubes should implement a different hypervisor. The whole thing seems trollish and clickbaitish.
To clarify, by “isolated”, I mean compartmentalized. I don’t mean “impenetrable” nor do I mean to imply that there are no threats to dom0 security. I’m saying that the claim that the OP quoted: " It just shows that there’s no Dom0 isolation at all.” is obviously not true.
I agree with all of your points. Regarding dom0 “isolation”, I was not speaking in absolute terms. Please see my above reply to @enmus
Yes, it is trivial to set up a bidirectional channel from dom0 via any networked VM and run a reverse shell. Why on earth would this be a “hack”?
@partition : I saw the video, I posted on the dev’s github as a “Task”, not as a “Bug” or an “Enhancement” or a “Support” or a “Security vulnerability” because I wanted to highlight the channel and eventually someone with more insight would take on.
That it was considered as “invalid” was one thing, YET “[I was] ask[ed] that [I] please post this on the Qubes Forum or qubes-users mailing list instead”, which I did. I didn’t have to explain any of the alleged hack, I was MYSELF asking “Interesting or not ?”
That you jump to conclusion is YOUR problem, that YOU pretend I stated Xen is comprised, which I didn’t, is YOUR problem, that you find my input " trollish and clickbaitish" is YOUR skewed perception of reality.
@enmus wrote that "So if there was a Xen bug then ‘the game is over’”.yet as “Joanna writing about this that they had to choose some platform if they don’t want to create their own - and they didn’t want” hence if Xen was flawed, perhaps it should be interesting to consider another well known hypervisor (NOVA) as replacement.
Anyway, as stated in the original ticked and by the author himself, it’s about Qubes 4.0.x, so maybe it isn’t even relevant to 4.1.x anymore.
Now if you obviously knows everything and consider newcomers with the same “benevolence” as typical Linuxian, I guess you won’t attract too much sympathy as an unwelcoming “niche platform” populated with obnoxious nerds.
Cool down, don’t put words into my mouth, and we’ll be able to move forward altogether toward a brighter future.
Understood. More succinctly…
No. 
B
Ok.
this is the first time i heard nova is popular (i almost forget it exist)
It’s nice to know I’m not the only one who does this!
Stating that it was being dismissed as invalid isn’t the whole story.
See the very professional reply from Marek (lead Qubes OS developer) [0].
Marek evaluated the claims, pointed out some solutions that were already available, assisted the OP with providing a more conceptual understanding of Qubes OS, talked about future roadmap, and most importantly, he encouraged the OP participate and provided pointers towards contributing.
It’s easy to simmer this situation down to “did Qubes OS get hacked” but Marek showed the bigger picture is more important: if you want to hack Qubes, understand the concepts deeper, know where the project wants to head, and help get more people involved and contributing. Those factors definitely help achieving a hacked Qubes OS where the right people know about it and are able to do something about it before it becomes a risk.
I definitely want the OP to continue down the path of trying to hack Qubes or finding security vulnerabilities. It’s not always just about a VM escape (see [1], [2], [3], [4], [5]). With the right understanding and support from the Qubes team, it could be a matter of time before another QSB is released found by the OP. And we should all welcome that.
Sorry… can’t let this go without a response.
Of course it’s the whole story. Look at the following link.
Notice it is the same user who posted someone else’s video clips and the same user who offered no additional insight or explanation regarding the nature of the videos. It was the same individual who drew premature conclusions after very little discussion of the matter. That’s why the user was told by one of the Qubes devs:
“…this does not appear to be suitable for qubes-issues …If, after reading our issue tracking guidelines you believe we are mistaken, please leave a brief comment explaining why. We’ll be happy to take another look.”
Regarding the response from Marek that you quoted, it was a completely different interaction from a different user. You are are defending the creator of this thread by citing someone who else was actually discussing vulnerabilities at length with the members of the Qubes team. There is a difference between offering no explanation about a random youtube video and discussing real security concerns along with a published explanation of potential vulnerabilities in Qubes. The latter allowed Marek to clearly address the matter…
t’s easy to simmer this situation down to “did Qubes OS get hacked”
The issue here was not reduced to anything. The issue here was unclear from the beginning. Repeated requests were made for the OP to clarify the nature of the claims. He offered next to nothing in the way of actual discussion before posting a suggestion for a new Qubes hypervisor.
I definitely want the OP to continue down the path of trying to hack Qubes or finding security vulnerabilities.
The OP has demonstrated nothing and said nothing to suggest that he has ever stepped foot on that path. You are quoting an exchange between a security researcher and the lead developer of Qubes - neither of whom have anything to do with the OP.
“Sorry… can’t let this go without a response.”
Because the OP (me, you can name me, I assure you) was asking for info, not going to lecture you on the “vulnerabilities” described in the videos. I looked first if the guy “Hubert” was around but obviously not, hence I posted the link as alleged “security hacks”.
Of course it would have been way easier for everybody if “Hubert” created an account on github/there to post his own finding instead to release cryptic videos on Youtube. But obviously you were, again, eager to jump to conclusions and pretend I was there to troll while ALL I was asking was “Interesting or not ?”
Where did I asked for or stated anything else in my original comment ?