Qubes: Un "Sistema Operativo" seguro y diferente

8. Analysis of potential attack vectors
There is no such thing as 100% secure OS, at least on x86 COTS hardware. The software and hardware is
simply too complex to analyze for all potential errors in case of x86 platforms. Qubes architecture is all about
minimizing the attack surface, so that we could focus on auditing only the most important parts of the system,
instead of every single application running there.
Below we present the summary of theoretical attack vectors. We believe all of those vectors are very unlikely
and expensive (in terms of developing an exploit for a potential bug). Nevertheless they represent potential
attack points. We should stress that other, mainstream OSes, like Windows or Linux, would have such a list
too, just much longer — tens or perhaps hundreds of pages long.
Below we assume the attacker compromised one of the VMs, and discuss potential attack vectors the attacker
might use in order to compromise other VMs.
8.1. 1-stage vs. 2-stage attacks
We can divide potential attacks on Qubes OS into two groups:
1. one-stage attacks, that require the attacker find only one bug and exploit it in order to compromise the
system (e.g. steal data from other VMs or compromise them),
2. two-(or more)-stage attacks, where the attacker would have to chain two different exploits targeting two
different bugs, in two different system components. E.g. one exploit to “get to” the storage domain, and
another attack to compromise Dom0 out of the storage domain.
It should intuitively be obvious that the likelihood of a 2-stage attack should be significantly smaller than the
probability of a successful 1-stage attack, nevertheless we include them in the attack surface analysis as
well.
8.2. Potential attacks vectors from any VM (1-stage attacks)
Potential bugs in the hypervisor
The hypervisor is the most privilege element of the system. Any attack on the hypervisor (e.g. exploiting a
buffer overflow in a hypercall) allows to fully compromise the system. As part of the Qubes project we try to
minimize the possibility of hypervisor exploitation as it has been described in one of the chapters earlier.
So far there has been only one overflow discovered in the Xen hypervisor, and it wasnʼt in the core Xen
code, but rather in the optional code in the special extension to the Xen hypervisor called FLASK security
module31. Incidentally this bug has been discovered and described by one of the authors of this document32.
We expect the hypervisor code footprint to be between 50,000 – 200,000 LOC (the smaller number is what
we expect to have after we start sliming down the current Xen hypervisor, which is closer in size to the latter
number).
Potential bugs in the Xen Store Daemon (in Dom0)
Xen Store Daemon runs in Dom0 and its potential compromise can be fatal, as the attacker can later gain full
control over Dom0. It should be determined if Xen Store Daemon can be run under restricted user account,
rather than using the root account, which might provide a minor level of additional security33.
There is also a theoretical possibility of logical errors in the Xen Store Daemon implementation. E.g. an unprivileged
domain might exploit a hypothetical bug in the daemon to read certain key values that are not to
be read by this VM, which might contain e.g. the keys used to encrypt the block device used for inter-VM file
exchange, in which case the attacker, that also controls the storage domain, could steal the contents of the
files being exchanged between the VMs.
Qubes OS Architecture
41
31 This is a good example to support the thesis that the less code in the hypervisor the better.
32 http://invisiblethingslab.com/resources/bh08/part2-full.pdf
33 Obviously we donʼt assume that OS-level isolation is really that effective, hence the use of the word “minor”. Itʼs expected that a
skilled attacker can find and exploit a kernel overflow to escalate from user to root in Dom0.
Xen Store Daemon uses very simple way of communication, built on top of the Xen shared memory and
event channel mechanisms, and also the protocol used is very simple, which should minimize the chances of
such attack vectors.
Nevertheless, the Xen Store Daemon, being a very prominent target, should be thoroughly evaluated before
commercial use of the system.
Potential bugs in the GUI daemon (in Dom0)
The GUI daemon also runs in Dom0, and its successful exploitation is always fatal (see discussion in the
chapter on GUI).
The GUI daemon uses the same underlying communication mechanism as the Xen Store Daemon uses, and
similarly simple protocol. Itʼs thus believed that the likelihood of a bug in the GUI daemon implementation
should be very small.
Potential CPU bugs
Modern processors are one of the most complex creations made by humans. It is hard not to think that there
might be a bug in a CPU that could e.g. allow for unauthorized ring3 to ring0 privilege escalation. Interestingly,
no such bugs have ever been publicly disclosed. The closest of what we can think of here would be the
SMM caching attack, incidentally discovered by the authors of this document (and also independently by
Loic Duflot) a few months ago34.
One should, however, note that a CPU bug would not only be fatal to Qubes OS — it would be fatal to any
PC-based OS.
There is not much we can do about potential CPU bugs, besides hoping that the CPU vendor did its job well.
Itʼs not possible to “audit” the CPU, for obvious reasons.
8.3. Additional potential vectors from driver domains (2-stage attacks)
All the theoretical attacks considered in this paragraph are 2-stage attacks, which means the following attacks
require two different exploitable bugs, in two different system components, at the same time, in order to
succeed.
Potential VT-d bypass
If the attacker was able to initiate an arbitrary DMA transaction by programing a device assigned to one of
the driver domains (e.g. the network card), the attacker would be able to compromise the system. Qubes
architecture relies on Intel VT-d to prevent devices assigned to driver domains from performing DMA to
memory not belonging to their domain. An attacker that could bypass Intel VT-d technology, e.g. by compromising
the Memory Controller Hub, could compromise the system.
So far no attack against Intel VT-d has been publicly presented. We anticipate such an attack would be very
non trivial to come up with. Also one should note, that in order to use it against Qubes OS, the attacker
would first need to compromise one of the driver domains, by exploiting a bug in the software running there
(e.g. a bug in the network driver, or network backend, or disk backend).
Driver domain to MBR attacks
An attacker that controls one of the driver domains can theoretically find a way to re-flash the firmware in the
device being assigned to the domain, e.g. the network card. The attacker can then attempt to program the
device in such a way that it waited for the system reboot and then, using a malicious DMA, infect the system
boot loader or MBR. This, of course, is not enough to subvert the system, as Qubes uses secure boot process
implemented with the help of Intel TXT.
Nevertheless, the attacker can now attempt to perform most of the attacks that are otherwise attributed below
to storage domain only (except for the attacks on VM storage frontends, see below, that is possible only
from the storage domain).
Potential delayed DMA attack on Dom0 (attack mostly from storage domain)
If the attacker controls the storage domain, he or she can infect the MBR or boot loader.
Qubes OS Architecture
42
34 http://invisiblethingslab.com/resources/misc09/smm_cache_fun.pdf
The infected boot loader can, in turn access the graphics card or the audio card device (because early in the
boot, before executing SENTER, there are no VT-d protections in place), and program it in such a way (perhaps
by re-flashing its firmware) that it will wait until Dom0 start and then performs a malicious DMA attack,
that e.g. installs a backdoor in Dom0.
Such an attack would work because the devices assigned to Dom0, i.e. the graphics card and the audio
card, are allowed DMA access to the whole Dom0 memory.
In order to prevent such hypothetical attacks, the hypervisor should allow domains (via an additional hypercall)
to set additional per-VM VT-d protections. Obviously the hypervisor should make sure that the domain
can only set more restrictive VT-d protections, rather than the other way round.
Potential TXT bypass (attack mostly from storage domain)
Intel Trusted Execution Technology (TXT) allows to have unprivileged security non-critical storage domain. If
the attacker was able to bypass Intel TXT (using a software only attack), the attacker, if already compromised
the storage domain, could compromise the whole system e.g. by modifying the hypervisor or Dom0
image on disk and rebooting the system.
So far two attacks on Intel TXT have been publicly disclosed. Incidentally both of the attacks have been discovered
by the authors of this document35.
Untrusted input to Dom0 from BIOS, e.g. malicious ACPI (attack mostly from storage domain)
Xen hypervisor and Dom0 kernel process several BIOS-provided inputs during boot. This includes e.g. the
BIOS e820 memory map, as well as the BIOS-provided ACPI tables. All the BIOS-provided input should be
treated as untrusted and handled with great care. One example of an attack exploiting this vector, is the already
mentioned ACPI AML methods that are executed by Dom0 kernel as part of power management activities.
The attacker can subvert the original ACPI tables and provide malicious AML methods for Dom0 to execute,
which can lead to Dom0 compromise.
More subtle scenarios include exploiting potential input processing errors in the hypervisor or Dom0 kernel,
e.g. buffer overflows resulting in the BIOS-provided data being intentionally miss-formatted (e.g. too long
fields in the e820 map).
All the Xen and Dom0 kernel code that process BIOS-provided input should be thoroughly reviewed.
All those attacks assume that the attacker is controlling the execution early in the boot process. This can be
a result of the attacker gaining control over the storage domain earlier.
Potential encryption scheme bypass (attack from storage domain)
For the storage domain to be security non-critical, it is important to trust the crypto scheme used for VM private
block device encryption and the shared root filesystem signing to be correctly implemented. Otherwise,
the attacker who gained control over the storage domain, could either steal the VM private data or inject malicious
code for other VMs to execute.
Potential attacks on storage frontends (attack from the storage domain)
An attacker that controls the storage domain might attempt to exploit hypothetical bugs in the other VMʼs
block frontends that communicate with the block backend hosted in the storage domain.
The block fontend drivers are very simple and thus it is expected that the likelihood of a potential bug there is
rather small.
Potential attacks on VM networking code (attack from the network domain)
An attacker that controls the network domain might attempt to exploit hypothetical bugs in the other VMʼs
network frontends, or their regular TCP/IP stack. The Xen network frontends are very simple and thus the
likelihood of a bug there is expected to be rather small. The regular TCP/IP stack (in contrast to e.g. WiFi
stack or WiFi driver) is usually a very well tested code, and thus it should be hard to find and successfully
exploit a bug in this stack (although more likely than a bug in the frontend).
Qubes OS Architecture
43
35 http://invisiblethingslab.com/resources/bh09dc/Attacking%20Intel%20TXT%20-%20paper.pdf and

http://invisiblethingslab.com/resources/misc09/Another%20TXT%20Attack.pdf.

8.4. Resistance to attacks from the (local) network
Because all the world-facing networking code executes in the unprivileged network domain, there is no direct
attack surface from the local network on the system.
There is, however, a possibility, that the attacker, who already compromised the network domain, e.g. by exploiting
a bug in the WiFi driver, can now try to exploit (another) bug in the networking stack of one of the
AppVMs, as explained in the previous paragraph. That would however requite a 2-stage attack.
8.5. Resistance to physical attacks
Below we analyze the low-cost physical attacks that could be performed in a matter of minutes against a laptop
left e.g. in a conference or hotel room, and how Qubes OS can resist them.
Resistance to Evil Maid attacks (trusted boot bypass)
As it has been described in the previous chapter on storage domain, Qubes boot process is designed to
withstand even sophisticated Evil Maid attacks.
Resistance to keystroke sniffing attacks (e.g. hidden camera)
Qubes OS can also resist simple key sniffing attacks that are targeted toward capturing the passphrase used
to boot the system. This can be achieved by the already mentioned trusted boot process that uses smartcard
to obtain the user secret, rather than the keyboard.
Relaying on OTP passwords to avoid keystroke sniffing attacks can be tricky…
We can imagine a naive implementation, where the disk master encryption key is re-encrypted with next
OTP password after each successful login. Thus, in order to unlock the system, the attacker must enter the
next OTP password from the list, and the previous OTP password(s) would not allow to decrypt the filesystem.
However, the attacker can, when having physical access to the system for some time (perhaps about 1-2
hours), create a complete copy (dump) of the hard disk content of the target laptop. Then, the attacker, after
capturing the next valid OTP password, can use it on the copy of the hard disk he or she just created, effectively
“replaying” what the user just did when entered the OTP password. So, even though, on the users laptop
the next OTP password would be required to unlock the system, the system running from a copy of the
disk that the attacker has requires the same password that the user just entered (and that we assumed has
just been sniffed).
One possible solution could be the use of a remote server that would be unlocking the master encryption
password and that would be taking care about incrementing the OTP passwordʼs counter. However the requirement
of always having network connectivity in order to unlock the system might be unacceptable by
many users. Additionally, the need to establish network connection so early in the boot stage would require
bringing up the network domain, which in turn would require also starting the storage domain, and this all
before even obtaining a passphrase/OTP password from the user. Additionally the client program that would
be verifying the OTP password with the remote server (and obtaining the master disk encryption key) might
expose system to additional attack vectors from the network (including attacks on the crypto protocol used
for this process). For all those reasons the solution with a remote OTP authorization is not recommended for
Qubes OS.
Much better solution seems to be to use the TPMʼs non-volatile storage to store the disk decryption master
key, or the counter for the OTP key. Thus, even if the attacker stole the laptop (which implies the attacker
would have access to the TPM), the attacker would be unable to boot the system using the once-used OTP
key, even if restored all the disk contents to the previous state, recorded before the user entered the key that
was sniffed.
Resistance to DMA attacks (e.g. malicious PCMCIA)
Due to the extensive use of VT-d, Qubes OS should be resistant to many runtime DMA attacks, e.g. when
the attacker inserts a specially crafted PC Card (also known as PCMCIA) that is supposed to use DMA in
order to compromise e.g. Dom0 and unlock the computer, or just steal some secrets from the memory.