This is “General Discussion” material. Moved it there.
SeL4 
AFAIK it’s not exactly true. The strength of Qubes’ compartmentalization lies mostly in the hardware virtualization. Especially if you minimize the interactions between important VMs, which is what you should do if security matters for you.
And isn’t this hardware virtualization controlled by Xen? I’m not technical, but isn’t hypervisor breakout or VM escape a thing?
Am I mistaken in believing that a sufficiently serious security breach of Xen, which underwrites everything in Qubes including dom0, means the attackers can potentially have access to everything built on the hypervisor either directly or via dom0? I’d like to be educated on the matter.
Also, don’t forget the unknown unknowns, like Spectre/Meltdown/Rowhammer, or even Log4Shell.
Edit: also found this article that’s directly relevant as it quotes Qubes devs:
Now I get that you mean PVH mode (which is the solution for the above, and has been implemented by default in all except VMs that use PCI devices) but can you say for certain issues of similar seriousness will never pop up in the future?
Yes. But how hard such escape is, depends on the virtualization technology. Before 4.0, Qubes used para-virtualized mode, resulting in escapes.
Perhaps a more knowledgeable person could correct me, but I think not. See also: Blue Pill (software) - Wikipedia and https://invisiblethingslab.com. A quote from the latter:
Rutkowska and her team have presented numerous attacks against virtualization systems and Intel security technologies, including a famous series of exploits against Intel Trusted Execution Technology. Their attack against Intel VT-d, allowing a full VM escape, is still the only one that has been demonstrated to this date, and they famously demonstrated that it is possible to break into Intel vPro BIOS and Active Management Technology. Rutkowska is also renowned in the security community for writing Blue Pill, the first hardware virtualization-based rootkit
As I mentioned before, preventing hypervisor escape is just one tiny part of the overall security (and we need more security audits for sure). We need systemic analysis of the attack surface, and what might be just as important, we want to be very dangerous targets thanks to advanced detection. Typical “western” adversary won’t risk a 0day to burn, and what is more important, a typical operator is not in the authority position to endanger the offensive capability if such a risk emerges (unfortunately, cannot say the same about “other types”),
i don’t think others have mentioned this yet, but TLAs are not in everyone’s threat model. with a wide-scale adoption of qubes, the security of the project would heavily increase due to more funding and scrutiny, and the bar for compromising a system (or deanonymizing users) would go from finding a browser exploit to breaking out of Xen (which, we would assume, would be a lot harder to do). it will also make TLAs actually have to devote time to breaking qubes, and i doubt they would burn Xen zero days to compromise the newly larger community of users (because target selection also becomes more difficult if we assume more and more people use qubes-whonix) – and more users to attack means IC is less likely to attack you, which gets zero days fixed after they’re used on more important targets (not considering that zero days could be stockpiled, but we also assume that finding them is difficult)
1 Like
But as of now, even if you are a high-value target for TLAs, Qubes is extremely unlikely to be your point of compromise. This may change.
I think we suck because we are safe.
Adversity is the mother of invention.
1 Like
As a statement, I take issue with that. As compared to… ?
2 Likes
And at the end of the day people fall on associating credit card with the anonymous email (kickass torrents owner), or posting an real email address under anonymous nick (Silk Road owner).
To hide is to lie, and it is so hard to lie all the time…
2 Likes
Are we safe because we’re a relatively tiny, niche OS?
To a certain extent, yes. All real-world security ultimately depends on how many resources your adversary is willing to expend. In practice, there’s no “perfect level of security” for a usable computing system that’s guaranteed to remain impervious even in the face of the rest of the physical universe being directed toward breaching it. (Sufficiently strong encryption can offer such guarantees for data at rest, but then you can never decrypt it. Once you involve an act of decryption, you have to assume a usable system with many more moving parts and potential points of attack, including the physical environment in which the computing system is used and the fallible sapients operating it.)
In this sense, it doesn’t matter whether it’s the Qubes OS we have today or a theoretical future version that’s a thousand times stronger. The general principle remains the same: Security is always relative to the strength of your adversary.
In practice, today, it’s likely that Qubes being relatively small and niche results in attackers spending relatively fewer resources on breaking it, but this depends on unknown factors. We don’t know how many high-value targets are using Qubes. (There is reason to expect that high-value targets might disproportionately self-select into using Qubes over non-security-focused OSes.) We do know that it’s nowhere near as popular as, say, Windows and macOS. An attacker motivated purely by profit stands to gain vastly more by targeting Windows users, so it’s unlikely that such an attacker would spend more resources for less potential gain by targeting Qubes. On the other hand, a well-funded attacker specifically targeting certain individuals might be motivated to devise methods to compromise whatever systems the target happens to rely upon. This might turn out to be Qubes, but Qubes might not be the easiest entry point against that target. That might instead turn out to be the target’s mobile device, home security system, place of business, friends, or something else.
6 Likes
Let’s say this:
- yes we are safe at home to avoid attacks
- no for you if you are not using Qubes OS due too many hacking attempts
- maybe we are sucks for using something that is not protecting our data from the spams
I agree this message for what our government has done for the bad projects
Let me share with you some historical trivia for context.
When Windows NT was first launched, it benefited for some time with this aura of safety and those who created exploits for its kernel were considered überhacker demigods.
At that time, Unix and Linux exploits were dime a dozen. Sendmail exploits week after week, wrecking havoc, it was the butt of the joke.
The only reason that Windows NT hackers enjoyed a short period of awe was because it was so novel that it required a learning curve to figure it out… and those who were really quick to crack that nut, enjoyed some reputation bump for being the pioneers, but after a while it became yet again another mundane system to crack habitually.
So, yes, of course security by obscurity will provide some level of safety but it will only work as a way to filter out the most common scripted attacks, and for tailored attacks it will act as an economical barrier of cost vs. benefit: Is it really worth to pour resources (time and money) into this obscure thing, when most of my targets are using off the shelf commercial shit? Or can we go around it finding another entry point, exploiting a system in its periphery that we already know how to attack?
If there is no other shortcut because, lets say the target’s OPSEC is tight and the guy is using only Qubes to connect to the digital world, AND if the target is so freaking valuable that it is worth it to dedicate a whole team to study this new OS to develop a chain of exploits for that particular target, then yes eventually this nut will be cracked as well.
So if we do a broad estimation, lets say a team of 10 dedicated hackers with an average salary of 100K USD for each, it would mean a minimum cost of a 1M USD a year dedicated only into focusing into one obscure OS for a specific individual.
At first these type of exploits would be highly coveted and remain in an arsenal without any disclosure.
But if as you say, if Qubes becomes more popular and enough “people of interest” start utilizing it, more eyes will be looking at this OS and several teams, both academic and foreign governments, will be looking at the same problems, and eventually some good old white hat will publish it for fame and glory at some conference, and then finally it will become trivialized when someone adds an update to metasploit making it available to any script kiddie.
At that point it won’t matter how clever or expensive it was to hack it, the most difficult hack eventually it will become trivial if there are enough collective interest to solve it.
And as with every apparent insurmountable complex problem, once you find the solution, you end up wondering if it was actually such a big deal. Hindsight is always 20/20.
And that’s why both the Xen and Qubes teams take security issues so seriously.
If a Xen or Qubes exploit were publicly published at a conference (say…without prior disclosure to the teams), i’m fairly certain you’d have a fix via Qubes updates within a week. And so, at that point, you’re protected.
Both Xen and Qubes are designed to minimize the exposed interfaces that code inside VMs can exploit to escape. In particular, Qubes’ design approach further minimizes this: e.g. designing the various Qubes protocols (gui, vchan, etc.) avoid parsing of complex/untrusted data sourced from VMs (one traditional method of VM escape exploit); e.g. Qubes developed and upstreamed Xen stub-domains which are, effectively, hardware-enforced sandboxes for QEMU. QEMU is quite complex and has had a long history of extensive security issues over the years, exposing Xen, KVM, etc. to issues if running in a privileged domain (as per usual in most environments, such as KVM). QEMU is required to support HVMs (e.g. sys-net for your wifi or a Windows OS or in general, that must see a traditional x86 PC hardware config).
Xen is already relatively lightweight. And yes, there are still XSAs and fixes for the XSAs semi-regularly. But if you look at the percent that rise to a security issue that will impact Qubes, it is low. This is because the Qubes team has designed the system to limit exposure.
B
There’s nothing more noble than those who protect others. Young versions of Giorgio Maone are out there but they need to be nurtured and helped.
The attacks that most seem to expect from some form of attack surface in the OS when in reality the most effective are passive in nature. The most effective hyperjack won’t be noticed and it will be the result of normal operations, not some flagrant ‘I gotcha’.
That security patches are published as regularly as they are is a demonstration of the current state of security. Both in that security improves but issues continue to exist.
Don’t trust computers. If you keep sensitive information on a networked computer or ‘smart’ device you deserve what you get.
Computer software and hardware of today feed the new ‘opiates of the masses’, convenience and entertainment. These are the real ‘attack surfaces’.
How many OSes come with a built-in security monitoring system; a system that detects and reports compromises? How many users are versed enough in forensics to protect themselves?
There is an extremely high trust level in the creators and maintainers being noble.
Oh, by the way, Have a Merry Christmas and Joyous New Year!!! (sincerely)
so much epic information here, thanks for creating this thread.
I took the freedom to change the subject line to the version of the question @adw posted “Are we safe because we’re a relatively tiny, niche OS?” It’s more to the point and also less disrespectful to everyone putting their time and energy into this project.
The answers so far – if I didn’t miss anything – didn’t account for the special nature of Qubes OS. It can’t be compared directly with other OSes as it is more of a Meta OS:
- it let’s you use multiple virtual machines concurrently with whatever OS inside you choose
- it provides ‘glue’ to route networking, input, output
- it provides strictly defined minimal interfaces for data exchange between qubes
- template based qubes add read-only system partitions
This in turn allows the user to spread their data and therefore risk among several virtual machines. The idea is not to prevent compromise but to expect it and minimize the damage. Yes, this part is based on Xen and it appears lots of people like to speculate about it’s security. But this arguing fails to account for the fact that Xen only comes into play when your qube is already compromised. Regardless of which OS you run inside that qube (the one you are apparently comparing Qubes OS to). On any “non-Qubes OS machine” now would already be game over. The attacker won and has all of your data. End of story.
Does Windows/Linux become more secure by running it in Qubes OS? No it doesn’t. What Qubes OS gives you is the ability to firewall that qube and you don’t have to “put all of your eggs in one basket”. So if that one qube goes, only the data that was in it get’s exposed.
I am less than mildly surprised most of you genuinely seem to overlook this basic architecture and frankly this should be your main reason for using Qubes OS. If you didn’t understand this part, then you are using Qubes OS as “magic pixy dust” and I am not surprised anymore at the form of the question.
Any other OS that has had more scrutiny can be run inside of your qube. You can go crazy there. The reason many of us don’t bother to go crazy with the hardening is the realization that once you have everything that is valuable compartmentalized into offline qubes eventual compromises of the online qubes aren’t that big a deal anymore … especially if those are disposable.
Yeah, but … XEN!!!
Ok, but now we hopefully agree that what we are really comparing is the attack surface and maturity of XEN in the form it is used in Qubes OS with the entirety of e.g. Windows or Linux. And from an attacker’s point of view it becomes even more clear: once they have a Windows/Linux based exploit they own everything that’s on a “normal” machine. On a Qubes OS machine they now own that qube, but then have to also have a XEN exploit that actually works in Qubes OS to get the rest of the data.
So it’s SuperHardOS™ against Qubes/XEN + SuperHardOS™. Qubes OS really is more of an additional layer of protection and an architectural trick to help you limit the damage of eventual compromise once your SuperHardOS™ was defeated.
3 Likes