Thanks!
I had thought of this, and I'm glad you updated the wiki to make it more
explicit.
I still think it's probably helpful for many drive-by untargetted
attacks. I imagine there's malware out there waiting to see if it's
running in Linux and then installing a rootkit in the kernel if it is,
never checking to see if it's in a VM, or running in Qubes.
So maybe it's a security feature in the same way that anti-virus
software is a security feature. :)
> 2) When considering an "air-gapped" Qubes AppVM, i.e. an AppVM which has
> no networking, one should remember about the possibility of the malware
> in that AppVM to leak secrets using a (sophisticated) covert channel,
> e.g. via CPU cache, to some other AppVM. This naturally assumes that
> this other AppVM has also been compromised and that the malware in the
> "air-gapped" machine cooperates with the malware in the other AppVM
> (which we assume is network-connected).
>
> Such covert channels through CPU cache has been described and even
> implemented in some "lab environments" and IIRC they might allow for
> bandwidths of even a few tens of bits/sec. It is unclear to me if such
> channels could be implemented in a "real world" system, where multiple
> VMs execute at the same time, each running tens or hundreds of
> processes, all using the same cache memory, but it's worth keeping in
> mind. Of course this wold require special malware written specifically
> to attack Qubes OS, and perhaps even specific Qubes OS version and
> perhaps specific Qubes OS configuration. Nevertheless might be possible.
I wonder, are there other covert channels that could be used to
communicate between AppVMs, or is CPU cache the only one?
> True air-gapping is generally hard. I remember I saw some papers about
> how a compromised air-gapped machine could establish a covert channel
> with another one using a mic and speakers.
Yup, this was allegedly what was going on with badBIOS. In laptops it's
generally very easy to physically remove the wifi card, and that
normally also contains the bluetooth interface (both of these might have
vulnerable firmware, even if the devices are "off" in the OS).
Speakers/mic are more difficult, but a simple way to close that hole is
to buy cheap earplugs, plug them into the speaker/mic ports, and cut the
remaining cable off.
> So, these were my comments to the article. I also have some questions to
> Micah, as he seem to be much involved into Tails:
>
> 1) So, what advantage there might potentially be of running Tails on
> baremetal vs. inside of Qubes HVM?
If malware in another AppVM manages to exploit Xen/Qubes and compromise
dom0, then it can spy on Tails. As unlikely as this is, it's still
possible, and I think this is the main advantage of running on baremetal.
Tails is also designed to not leave any trace of it ever running on your
computer. When you boot to it on baremetal it doesn't touch the hard
drive. Obviously this wouldn't be the case of you have a VM dedicated to
using it -- however I think this feature is only useful for a very
specific threat model. (Like, if you get stopped at a checkpoint in
Syria and they search your computer for encryption software and arrest
you if they find it; I've heard this this happens.)
The other advantage is that Tails is designed as a live distro. There's
no concept of "installing" it on a computer, which means you need to
mount the DVD image each time you boot the HVM. If it detects that it's
running in a VM, it pops up a warning on boot telling you that if the
host machine is compromised Tails can be compromised too.
And finally, using a "persistent volume" in Tails is very useful, and
it's impossible (or at least very challenging) to create one inside of a
VM, (or while booted to a DVD). The "persistent volume" expects you to
be booted from a USB stick, and helps you create an encrypted partition
on it that can automatically restore specific files each time you boot
(e.g. a folder for documents ~/Persistent, and also ~/.gnupg, ~/.purple,
etc.).
> 2) Considering Tails running on baremetal (or even inside *one* Qubes
> HVM): if the attacker compromises your Firefox through a 0day, what
> prevents the attacker from disabling tor or just reading various info
> identifying the user (e.g. MAC, real IP, etc)? Does Tails use some form
> of sandboxing like SELinux or LXC?
If Firefox (or in the case of Tails, Iceweasel) gets compromised, the
attacker can then do anything that the "amnesia" user can do, such as
try to store malware in the persistent volume (which isn't the simplest
-- nothing runs automatically, and it doesn't store your whole Iceweasel
profile, only your bookmarks, etc.). But the attacker could definitely
exfiltrate your data.
You can also choose to boot without mounting your persistent volume, and
this is recommended unless you specifically need it. And unless you
change a setting on boot, the Linux user in Tails doesn't have root, so
the attacker then needs to use a local root exploit before it can do
things like modify the data on the Tails USB to contain persistent malware.
I believe there's really networking things going on that make it so if
you stop Tor everything stops working and doesn't fallback to not using
Tor. However, an attacker (even without root) can almost certainly
compromise the anonymity of Tails.
It looks like sandboxing is in the works, but won't be ready for some time:
https://labs.riseup.net/code/issues/5385
https://labs.riseup.net/code/issues/5525
But it's also true that it's significantly more difficult to target a
Tails or Tor Browser user than it is to target most other people. The
browsers look identical, can't be uniquely fingerprinted, and aren't
accustomed to leaking the same unique cookies all the time like normal
browsers are.
In practice, if you want to target a specific Tor user you really need
to target *all Tor users* of a specific website and hope your target is
one of them, e.g. like what happened in the Freedom Hosting situation.
> Anyway, thanks for promoting Qubes OS!
>
> Cheers,
> joanna.
>
--
Micah Lee