Minor UI Bugs

[Andrew B]

1) qubes-dom0-update
"Using xxx as updatevm to download updates for Dom0, this may take some of time..." -> "Using xxx as UpdateVM to download updates for Dom0; this may take some time..."

2) qvm-copy (or any RPC service?) to nonexistent domain
"Domain 'xxx' doesn't exists" -> "Domain 'xxx' doesn't exist"

3) Changing the color/label of a running VM
Window border colors do not change on running VMs (i.e. if it was 'blue' before and changed to 'green', all windows are 'blue' until the VM is restarted). Either the label should not be changed at runtime (so, the drop-down box should be disabled), or the change should immediately affect all windows.

Andrew

PS: Is qvm-copy-to-vm not an infoleak? If I copy a file from an exploited DispVM to 'vault-supersecret', the exploited DispVM now knows I have a VM named 'vault-supersecret'. Not a problem on its own, but could help later targeted attacks. Would it not be better to have 'qvm-copy-from-vm' instead of 'qvm-copy-to-vm' (i.e. a "pull from" rather than "push to" model)?

[Marek Marczykowski-Górecki]

On 27.10.2014 16:37, Andrew B wrote:
> 1) qubes-dom0-update
> "Using xxx as updatevm to download updates for Dom0, this may take some of time..." -> "Using xxx as UpdateVM to download updates for Dom0; this may take some time..."

Fixed.

> 2) qvm-copy (or any RPC service?) to nonexistent domain
> "Domain 'xxx' doesn't exists" -> "Domain 'xxx' doesn't exist"

Fixed.

> 3) Changing the color/label of a running VM
> Window border colors do not change on running VMs (i.e. if it was 'blue' before and changed to 'green', all windows are 'blue' until the VM is restarted). Either the label should not be changed at runtime (so, the drop-down box should be disabled), or the change should immediately affect all windows.

Blocked the change in Qubes Manager.

> Andrew
>
> PS: Is qvm-copy-to-vm not an infoleak? If I copy a file from an exploited
> DispVM to 'vault-supersecret', the exploited DispVM now knows I have a VM
> named 'vault-supersecret'. Not a problem on its own, but could help later
> targeted attacks. Would it not be better to have 'qvm-copy-from-vm'
> instead of 'qvm-copy-to-vm' (i.e. a "pull from" rather than "push to"
> model)?

IMHO this info leak is negligible. If one is aiming for targeted attack,
guessing VM names isn't much a problem (start with defaults like 'banking' for
example). Anyway VM names should give nothing to help with breaking the isolation.
But changing file copy approach, will greatly reduce usability - the user
would need to provide source file path in target VM (additional copy&paste
operation). Even when some special directory would be used for that, one still
need to copy/move the file there first, then launch the copy operation (from
another VM).
BTW Currently RPC target domain do know the source VM name.

--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[Andrew B]

Yes, that would be annoying. What if instead the destination VM name is (optionally?) unspecified and Dom0 prompts for the name, like how the "Copy to other AppVM" works (but done in Dom0)? Not sure it's worth the implementation effort, but would be nice.

Andrew

[Marek Marczykowski-Górecki]

Actually this is idea sounds good. It can even improve usability - when the
user enters the VM name in dom0, the same prompt can be used for confirmation
the transfer.

https://wiki.qubes-os.org/ticket/910

[Axon]

Andrew B wrote:
> If I copy a file from an exploited DispVM to 'vault-supersecret', the exploited DispVM now knows I have a VM named 'vault-supersecret'. Not a problem on its own, but could help later targeted attacks.
>

Not to be pedantic, but if you've copied a file from an exploited DispVM
to 'vault-supersecret', your supersecret vault has already been
successfully attacked.

[Andrew B]

Well, that's not necessarily the case. Perhaps vault-supersecret contains only plaintext backups of keys or notes or something. At the very least, vault-supersecret should not be exploited until it runs something that interprets that data.

But perhaps I chose a bad example. I copy a file from an exploited DispVM to 'my-torbirdy', the rest still applies (and assuming I only email this file and never explicitly interpret it, it's probably not going to exploit 'my-torbirdy'). It seems better to keep this information out of the source VM, especially since it apparently makes things simpler, anyway.

Andrew

[7v5w7go9ub0o]

Arguably, copying a text file using qubes-copy-between-VMs from an
infected VM to vault should be very safe:

1. The copy is handled by DOM0, using "safe" GUI or cl tech.
2. The text file is not executable; even if it is executable, it'll be
handled as text.
3. The vault is simply a repository - not connected to the net, nor
itself ever hosting a working process. It would be a "safe" place to
store your virus samples.

For e.g., I store my mail and newsgroup messages in vault; copy them out
to a DispVM for routine use; at session end I copy the updated messages
(text) back to the vault for storage, knowing that there could be
malware within a mail document. I just don't see the risk to vault
(though obviously, the temporary DispVM within which I run TBird is
subject to all sorts of mischief born from the messages, and from its
connection to the NET.)

[Vincent Penquerc'h]

On 31/10/14 17:24, 7v5w7go9ub0o wrote:
> For e.g., I store my mail and newsgroup messages in vault; copy them out
> to a DispVM for routine use; at session end I copy the updated messages
> (text) back to the vault for storage, knowing that there could be
> malware within a mail document. I just don't see the risk to vault

It's *probably* OK.
The idea is that storing those files in a VM entails some kind of
residual risk. For instance, if you use tar+gzip inside that VM to
create archives of your files and unpack them for daily use in another
VM, it could be that there'd be a bug in tar that overflews a buffer
when faced with a number of files with specific sizes, or one in gzip
that does when faced with a certain binary string. The VM could then get
pwned via such a vulnerability being exploited. It can then communicate
with the original source VM via side channels to exfiltrate whatever
interesting stuff is also in the VM, and the original VM has network access.
Now, just copy is harder to exploit of course, I don't know what you do,
but... how about file sizes or metadata exploiting the filesystem layer
? Improbable, but theoretically possible.

[7v5w7go9ub0o]

Dang! Thanks!!

I take your point on tar+gz, and in fact frequently run that specific
utility within vault as part of routine copying, and also for routine
archiving. :-( . At this point, I expect to move the archiving outside
of vault (to DispVM), and replace tar as part of inter-VM moving.

I presume that for my approach to make sense, vault must be as purely a
repository as possible.

As to copy tools, between VMs I use "qvm-run --pass-io" or rt-click
within nautilus.

I don't understand the filesystem layer potentiality you mentioned -
please elaborate. Also, would that be an issue with 'cp'?

[Vincent Penquerc'h]

On 01/11/14 13:43, 7v5w7go9ub0o wrote:
> I don't understand the filesystem layer potentiality you mentioned -
> please elaborate. Also, would that be an issue with 'cp'?

Well, technically, the filesystem layer will process untrusted data (the
incoming files), similarl to what gzip or tar would. There's just a lot
less complex manipulation/interpretation of that data: file contents are
(hopefully) irrelevant, except maybe holes for sparse files, though the
attached metadata might be non trivial (ACLs, dates). Copying a file is
probably pretty safe though.