Home » Articles » Does Qubes OS Have a Security Leak?
Click Here To Hide Tor

Does Qubes OS Have a Security Leak?

Sandboxing is a security mechanism supported by OPSEC experts to defend against cyber-attacks, as well as a method to prevent loss of data.  In spite of its widespread use, is sandboxing enough to deter data intruders from pilfering massive data, or is it another hyperbole paraded as truth?

The question remains: if encryption or cryptographic methods have security leaks, then how exactly does domain sandboxing work?  In theory, wouldn’t it depend on cryptographic methods to prevent domain A from accessing the data of domain B?

Sandboxing can be defined as a method of creating a partition between domains, or a method of separating domains from one another.  Logically, it’s similar to a military training facility: you can train with potentially lethal weapons and tactics in a controlled environment, while minimizing the risk of actual damage and injury.

Technically, although Qubes is not the only operating system to support virtualization, it is the first operating system with domains allocated to special functions.  Polish computer security researchers Joanna Rutkowska and Rafal Wojtczuk began working on Qubes in 2010.   The method of sandboxing employed by Qubes differs from the day-to-day virtualization implemented by most software vendors.

Qubes’ virtualization is based on Xen, an open source hypervisor model.  It is often touted as the best by users with extensive experience.

A hypervisor is simply a virtual machine (VM) monitor which enables operating systems to host more than one VM on a host machine.  This is also known as virtualization.  Qubes OS is designed to provide security by isolation.

Qubes OS features the following function virtual domains for users:

Dom0

Dom0 is the most privileged domain out of all the domains, as well as the most sensitive.  It has direct access to the host hardware.  Being that it is sensitive, it is isolated from other domains, in particular the NetworkVM.

Dom0 hosts the GUI domain and controls the graphics device, as well as input devices, such as the keyboard and mouse.  The GUI domain runs the X server, which displays such things as the user desktop, and the window manager, which allows the user to start and stop the applications and manipulate their windows.

AppVM

AppVMs are VMs used for hosting user applications, such as a web browser, an e-mail client, or a text editor.  For security purposes, these apps can be grouped into different domains (e.g. “personal,” “work,” “shopping,” “bank,” etc.).  The security domains are implemented separately.  Think of VMs as being isolated from each other as if they were separate physical computers.

NetworkVM

The network mechanism is the one most exposed to security attacks.  For this reason, it is isolated in a separate, unprivileged VM, called the Network Domain.  An additional proxy VM is used for advanced networking configuration.

Storage Domain

Disk space is saved by virtue of assorted VMs sharing the same root file system in a read-only mode.  Separate disk storage is only allocated for the user’s directory and per-VM settings.  This allows software installation and updates to be centralized.  Of course, some software can only be installed on a specific VM.  Encryption is used to protect the file systems, so that the storage domain cannot read confidential data owned by other domains.

Among the domains or VM’s on Qubes OS, the NetworkVM is known to be the most vulnerable to attack vectors.  Also, within the AppVM, a user is more likely to be attacked by viruses, Trojans, keyloggers, and other types of malware.  Thus, it is the chief reason why the developers of Qubes decided to increase the proximity between the Dom0 and the NetworkVM.

It seems that the developers of Qubes believe that the best way to protect the Dom0 from keyloggers or Trojans is separate it from the AppVM.  In theory, we can assert that it is at least safe to operate on Qubes, but this isn’t always the case.

Is it Safe?

According to the technical documentation concerning Qubes’ structure, domains are separated from each other via encryption.  Like the Dom0, the storage domain is protected from other domains via encryption to prevent malware in other domains (such as the NetworkVM) from spreading.

If the storage domain were to be part of, or closely connected to, other domains, then the concept of security by isolation does not practically implement its intention to secure domains from each other.

However, those in the OPSEC industry should (by now) be aware of how connected devices, or even separated devices like a wireless keyboard and computer, are susceptible to malicious agents.

Even before I move on to how hackers can manage to take advantage of Qubes’ intention to protect domains by isolation, let’s ponder over the following questions:

  1. Why should Qubes allow users to set domain policies on their own, instead of implementing a wizard tool to automate settings? Is manual configuration better than wizard configuration?
  2. Is the encryption between the storage domain and others resilient enough without hidden bugs?
  3. Is the Dom0 completely protected from rootkits?
  4. How does the encryption mode between domains prevent viruses from moving the NetworkVM to the StorageVM?

Problems with Qubes’ Security Methods

Personally, I don’t have any problem with Qubes.  That being said, if Rutkowska confirmed that it is impossible to avoid bugs, then how can she assure users that Qubes is capable of sandboxing Trojans and malicious software from domains on Qubes?

In spite of Rutkowska’s opinion that the sandboxing method is secure, there are two other areas and techniques which could break the isolation method being implemented by Qubes developers.

It appears that Qubes depends on a backup system to prevent huge losses of data.  By default, the backup system relies on a weak key derivation function (KDF).  For that reason, it is recommended that users select a high-entropy passphrase for use with Qubes backups.

In all honesty, however, I have yet to find out if the backup system is a better method of avoiding heavy losses of data.  According to Qubes’ security team, a user can send backup documents to the AppVM.  My question here is: does the user know whether or not the AppVM is devoid of worms or viruses?

First Area of Vulnerability: According to Rutkowska, users are allowed to configure domain settings on their own.  The problem with this is that not all users are familiar with technical settings.  As HAL 9000 said in 2001: A Space Odyssey, “It can only be attributable to human error.”  It’s fair to assume that hackers would be aware of manual security policies, take advantage of haphazard configuration, and eventually inject viruses and Trojans into the user’s domain.

In other words, it stands to reason that hackers would count on human error to leave vulnerabilities in a user’s domain.  In spite of the isolation methods implemented by Qubes, users’ unseen mistakes may act as vectors, or security holes, which could compromise Qubes’ in-depth security.

Second Area of Vulnerability: Qubes does not allow users to ‘send’ or ‘transport’ files and folders; instead, it gives them the ability to copy and paste these resources.  For example, let’s assume that a user downloads a file or program from a phished website (disguised as an https site).  Later, the file or program downloaded from the phished website could be copied from the AppVM to the StorageVM.

The StorageVM is encrypted from the NetworkVM to prevent replication of malware.  Is the encryption method employed by Qubes secure enough to prevent malicious software in the AppVM from attaching itself to the StorageVM?

In conclusion, we may one day hear of a new zero-day attack on Qubes OS.  Qubes’ complexity is not invulnerable to compromise, but it is still more reliable than most operating systems.

So, while it may not be “invincible,” so to speak, it is still a viable option.  Just be aware of its limitations.

13 comments

  1. Hard to take you guys seriously when you can even spell the OS name properly. I mean seriously ffs.

  2. A true journalism masterpiece…

    “If the storage domain were to be part or closely connected to other domains, then the essence of security by isolation does not practically implement its intention to secure domains from each other.”

    – What does it mean? Is it well-formed English? (I
    really doubt about it, but I must admit English is not my mother tongue).

    “Softwares” (?)
    – Good God, please stop.

    “Why should Joanna []”
    “But if Joanna []”
    “In spite of Joanna’s opinion []”

    – Who?

    “Also within the App Vm, a user is likely to be attacked by viruses, trojans, keyloggers, and other malicious softwares . Thus, it is the chief reason why the developers of Qubes OS decided to increase the proximity between the Dom0 and the Network Vm.”

    – A possible rephrase of the Author’s sentence is “Since users are likely to be attacked by malware in the Application domain, developers increased the proximity (that is vicinity, adjacency, closeness) between the Administrative and the Network domains”. Please, would you explain how that vicinity should help with the protection from malware attacks?

    There are many more pearls buried in this piece and in other “featured” articles written by the same enlightened author (Michael Atobra Aboagye). Please skim that other nonsense about bug discovery at /2016/03/10/should-we-encourage-bug-discovery-and-neglect-pen-testing/.

    To anyone here at Deepdotweb who is responsible for the contents…

    Watch out of ill-designed and badly implemented “featured” technical articles like the Aboagye’s ones: they should be actively avoided since they are pure malware that could destroy the reputation of a news site.

    You don’t have to believe my words when I say articles like these are so toxic. Please ask anyone who possesses a computer science degree and who is also able to write plain English to give an informed technical opinion on such an article.

    Zoey Turing

  3. isn’t good grammar required on DDW? what the fuck is “Does Qubes OS Has A Leak Hole ?”

    come on now.

    • Zoey Turing

      I was so concerned about the low quality of the technical content here provided that I didn’t even noticed the “Does [] has []” in the title.

      Can I know how you here at Deepdotweb select writers and revise their content? You’re telling stories about the ‘wild side’ of the web, but it doesn’t necessarily imply your “featured” authors have to express themselves like a savage would do in a b-movie.

      Zoey Turing

  4. What a load of shit. Reads like FUD from someone that wanted to obscure their writing so ran their article through translate.google a few times. Any coherent message that may have existed was completely garbled. Try again, in English this time, DDW.

  5. This essay purports to critique implementation of security in Qubes. I am not an expert in either Qubes OS or in operating system security, but I am a user of Qubes OS. I understand a little about what the system does, and what it does not do.

    First, no general-purpose operating system keeps all users completely safe. To do so would requre the OS to lock users out of nearly all the functionality we expect from a general-purpose OS.

    For example, the author speculates about transfer of malicious files between Qubes VMs. Qubes uses the Xen hypervisor’s shared memory rather than a global clipboard, and the OS keeps one app VM from parsing the file structure of another. File copying is in that sense more secure than in Windows. Can a user copy malware from one app VM to another? Yes. But the ability to copy files — functionality — suggests a compromise with absolute isolation between app VMs.

    For another example, Qubes provides a separate firewall configuration for each app VM. A user can, if she wishes, give the “untrusted” VM very permissive firewall settings. Would that be smart? No, not really. But the ability to set firewall parameters — functionality — again suggests a compromise with unequivocal, unilateral lockdown of app VM firewalls.

    No real-world OS is invulnerable. Not if it allows the user to modify files and connect to outside resources. And disallowing those functions would limit the system to the point of making it useless.

    So it seems to me that the author of this essay confuses user responsibility with operating system security. The OS is one part of the security equation; the user is another. The value of an OS like Qubes is that it makes it much easier for a user to manage security on the system, not that it makes the system intrinsically invulnerable. To the author’s question, “Does Qubes OS Has A Leak Hole?” one might ask another question: Does the author’s understanding of security consist of anything but conceptual holes?

Leave a Reply

Your email address will not be published. Required fields are marked *

*

Captcha: *