backupvm security

[Axon]

Suppose you have a backupvm, the function of which is to store your
Qubes backup files (created by qvm-backup) and upload them to a remote
server. This backupvm must be somewhat trusted, because you must enter
your remote server credentials there. (If an attacker obtains them, he
can delete your remote backups or do other nasty things.) Now suppose
you want to store your backup files on an external USB HDD attached to
this backupvm. While the backupvm must be somewhat trusted, the usbvm
must be untrusted (for reasons covered in the wiki and in other
threads). Therefore, backupvm != usbvm. (Suppose backupvm == green and
usbvm == red.) The obvious solution is to pass the USB HDD through to
the backupvm with qvm-block, but is this safe? The usbvm still has r/w
access to the USB HDD even while it is connected to the backupvm. Does
this "sharing" entail that the backupvm becomes equivalent in
trust-level to the usbvm?

[Joanna Rutkowska]

I wouldn't worry that much about an attacker being able to remove my
backups from a remote server via compromising by backupvm via USB
attacks. There are probably million other ways for the attacker to
achieve this goal.

But if you really wish to address your specific problem -- just use
usbvm as your backup vm whenever you backup onto a usb disk, and use
some other vm for uploading to a remote server.

joanna.

[Axon]

Joanna Rutkowska:

> On 02/03/14 04:10, Axon wrote:
>> Suppose you have a backupvm, the function of which is to store your
>> Qubes backup files (created by qvm-backup) and upload them to a remote
>> server. This backupvm must be somewhat trusted, because you must enter
>> your remote server credentials there. (If an attacker obtains them, he
>> can delete your remote backups or do other nasty things.) Now suppose
>> you want to store your backup files on an external USB HDD attached to
>> this backupvm. While the backupvm must be somewhat trusted, the usbvm
>> must be untrusted (for reasons covered in the wiki and in other
>> threads). Therefore, backupvm != usbvm. (Suppose backupvm == green and
>> usbvm == red.) The obvious solution is to pass the USB HDD through to
>> the backupvm with qvm-block, but is this safe? The usbvm still has r/w
>> access to the USB HDD even while it is connected to the backupvm. Does
>> this "sharing" entail that the backupvm becomes equivalent in
>> trust-level to the usbvm?
>>
>
> I wouldn't worry that much about an attacker being able to remove my
> backups from a remote server via compromising by backupvm via USB
> attacks. There are probably million other ways for the attacker to
> achieve this goal.
>

Really? I figured it would be at least somewhat difficult, assuming that
your backup "service provider" (Amazon or Dropbox or whatever) has
appropriate security measures in place, and you use a strong password.
Am I being naive here?

> But if you really wish to address your specific problem -- just use
> usbvm as your backup vm whenever you backup onto a usb disk, and use
> some other vm for uploading to a remote server.
>

Just to make sure I'm following you: Do you mean to perform every backup
twice, sending one copy to the usbvm and the other copy to the backupvm?
(Assuming you want to store every backup file both locally and in the
cloud.) I suppose that's a pretty good compromise, since you can just
delete the copy in the backupvm (after uploading) to save disk space,
and the backup creation process is pretty fast.

But does this mean that it is indeed "insecure" to pass a USB block
device through to an AppVM, in the sense that any attaching a USB stick
to the "vault" VM while the usbvm possesses the USB controller
effectively makes the "vault" VM as untrusted as the usbvm? If so, we
should probably add more explicit warnings in the wiki against this
(though we've already been warning against similar behavior for a quite
a long time now).

> joanna.
>

[Joanna Rutkowska]

But their admins can remove any of your files with ease, if they only
want to (or are asked by the gov).

>> But if you really wish to address your specific problem -- just use
>> usbvm as your backup vm whenever you backup onto a usb disk, and use
>> some other vm for uploading to a remote server.
>>
>
> Just to make sure I'm following you: Do you mean to perform every backup
> twice, sending one copy to the usbvm and the other copy to the backupvm?
> (Assuming you want to store every backup file both locally and in the
> cloud.) I suppose that's a pretty good compromise, since you can just
> delete the copy in the backupvm (after uploading) to save disk space,
> and the backup creation process is pretty fast.
>

I just meant that if that bothers you that a USB attack might steal your
network storage login credentials, then just use a separate VM to backup
to a USB device (whenever you feel like backing up to a USB device), and
a separate one to upload to the cloud (whenever you feel like uploading
to the cloud). The VM that plays a rols of a backup vm doesn't need to
be special in any way, so anything can be a backup VM (well a
Linux-based AppVMs that is).

> But does this mean that it is indeed "insecure" to pass a USB block
> device through to an AppVM, in the sense that any attaching a USB stick
> to the "vault" VM while the usbvm possesses the USB controller
> effectively makes the "vault" VM as untrusted as the usbvm? If so, we
> should probably add more explicit warnings in the wiki against this
> (though we've already been warning against similar behavior for a quite
> a long time now).
>

Passing a block device might be insecure, because e.g. the filesystem
metadata on this device might be malformed and tried to exploit some bug
in the dest AppVM's kernel.

joanna.

[Axon]

Joanna Rutkowska:

Very true, of course. I just meant (non-gov/non-insider) "hackers." But
of course anyone concerned about gov/insider adversaries performing this
kind of DoS should not rely on a remote server unless it's maintained by
themselves or someone they personally trust.

>>> But if you really wish to address your specific problem -- just use
>>> usbvm as your backup vm whenever you backup onto a usb disk, and use
>>> some other vm for uploading to a remote server.
>>>
>>
>> Just to make sure I'm following you: Do you mean to perform every backup
>> twice, sending one copy to the usbvm and the other copy to the backupvm?
>> (Assuming you want to store every backup file both locally and in the
>> cloud.) I suppose that's a pretty good compromise, since you can just
>> delete the copy in the backupvm (after uploading) to save disk space,
>> and the backup creation process is pretty fast.
>>

(I just realized that qvm-copy could also be used here, as well.)

>
> I just meant that if that bothers you that a USB attack might steal your
> network storage login credentials, then just use a separate VM to backup
> to a USB device (whenever you feel like backing up to a USB device), and
> a separate one to upload to the cloud (whenever you feel like uploading
> to the cloud). The VM that plays a rols of a backup vm doesn't need to
> be special in any way, so anything can be a backup VM (well a
> Linux-based AppVMs that is).
>

Understood. Thanks.

>> But does this mean that it is indeed "insecure" to pass a USB block
>> device through to an AppVM, in the sense that any attaching a USB stick
>> to the "vault" VM while the usbvm possesses the USB controller
>> effectively makes the "vault" VM as untrusted as the usbvm? If so, we
>> should probably add more explicit warnings in the wiki against this
>> (though we've already been warning against similar behavior for a quite
>> a long time now).
>>
>
>
> Passing a block device might be insecure, because e.g. the filesystem
> metadata on this device might be malformed and tried to exploit some bug
> in the dest AppVM's kernel.
>

Indeed, or perhaps even more likely: A piece of malware could be written
to the device in the usbvm and executed in the dest VM (either by some
auto-preview or by an unsuspecting user, e.g., if the file replaces a
previously "trusted" file with the same name).

I assume this is possible because I just now created a file on a USB
stick in my usbvm which then showed up in the AppVM to which the same
USB stick was attached (after remounting). (Actually, now that I think
about it, the fact that this is possible was probably already blatantly
obvious to everyone except me. :) )

> joanna.
>
>

[cprise]

There is a case where the risk of a malformed filesystem is essentially
eliminated: If you encrypt the entire disk and then format it using a
trusted vm. Then your trusted backup vm is safe from attack from the
passthrough drive as long as you never unlock it from an untrusted vm or
machine.

[Joanna Rutkowska]

But the (potentially malformed) encryption header is still a potential
source of attack against the encryption software that will try to parse it.

j.

[cprise]

No doubt there is the /potential/, but still among the hardest to attack
nonetheless. And if one is afraid of convoluted plaintext headers (which
Qubes relies on anyway, in the form of signed packages and encrypted
backup archives, and even LUKS for the root filesystem) then LUKS can be
replaced on the backup disk with plain dmcrypt or
truecrypt/realcrypt/tcplay.

At some points, you have to rely on correctness even in an
isolation-based system. If I'm going to have to choose which areas of
the system need to be correct/hardened (representing the attack surface)
then I'm going to prefer crypto tools for this role. And Qubes already
does that; what I'm suggesting is a usage scenario that is in line with
established Qubes use cases and assumptions about securing a system with
crypto.

[Joanna Rutkowska]

Yes, Qubes does rely on correct handling of rpm packages headers, but
our backup system does not -- please see the thread were this was
discussed specifically (and why we used openssl instead of gpg).

> At some points, you have to rely on correctness even in an
> isolation-based system. If I'm going to have to choose which areas of
> the system need to be correct/hardened (representing the attack surface)
> then I'm going to prefer crypto tools for this role. And Qubes already
> does that; what I'm suggesting is a usage scenario that is in line with
> established Qubes use cases and assumptions about securing a system with
> crypto.
>

Sounds correct to me.

joanna.