Are we safe because we’re a relatively tiny, niche OS?

General Discussion
3

I would say that security as a whole would become considerably more hardened in the face of greater threats - resulting in defense measures that dwarf the security standards of today.

However, that doesn’t mean that the average Qubes user would realize the same relative defense advantages over others as the pool of skilled attackers would increase.

The average Qubes user would not be able to rely on “out of the box” solutions or simply being one of the few “in the know” to enjoy the relative defense advantages of today. While the playing field would be hardened, it would be more even - requiring even more knowledge and skill for the average user to enjoy the same relative advantages against common threats.

That’s of course assuming that the tendency for “red teams” to be one step ahead of “blue teams” remains the case. I suppose it’s possible that innovations in computer science and technology could lead to a global tendency towards “blue team” dominance, but I suspect that underlying political and economic incentives will likely prevent that from happening. For some reason, the world seems to innovate, create and grow more when dealing with significant threats both real and perceived.

4

As a thinfoil hat nerd, my comment couldn’t be other than: It would be like in sports. Big teams don’t buy great players to play for them, but not to play for the competition. And there, most of them sit on the bench, waiting for… Godot?

Qubes forks would be inevitable.

5

I think Linux isn’t as secure as some open source evangelists would like people to believe, so the strength of Qubes lies in its compartmentalization, which is based on entirely on the assupmtion that Xen is hard to penetrate.

With virtualization already a key part of how cloud services operate, it isn’t a stretch to think that it is already in the crosshairs of malware developers–just not at the priority level that mass adoption of Qubes would lead to.

Xen is a relatively bloated hypervisor compared to other solutions, and my impression is that bloat equals complexity equals vulnerability (cf. Log4Shell). Once the demand is there, Xen is in trouble. Chain whatever findings to Linux vulnerabilities, and Qubes is in trouble.

One solution might be to move to a better hypervisor (SeL4?).

Also interesting is the implications this chain of thought has for Qubes open hacking competitions with rewards–what should ITL be responsible for if novel Xen and/or Linux attacks, and not Qubes-code-specific attack were used? Should ITL still be responsible? If not, why bother with the competition? Any competition with payouts should be in tandem with the developers of these software platforms.

3 Likes
6

This is “General Discussion” material. Moved it there.

7

SeL4 :+1:

8
9

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.

10

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?

11

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

12

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”),

13

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
14

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.

15

I think we suck because we are safe.

Adversity is the mother of invention.

1 Like
16

As a statement, I take issue with that. As compared to… ?

2 Likes
17

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
18

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
19

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
20

I agree this message for what our government has done for the bad projects

21

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.

22

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