Compromised via qvm-move/qvm-copy?

General Discussion
1

If I want to rescue data from a compromised AppVM to another VM, it would be possible for an attacker to replace qvm-move with their own version. This version would then copy not only my data but also the attacker’s scripts.
If I only back up 10 text files, it’s immediately obvious if other files have been copied illegally.
But not if there are 1,000 files in 100 subfolders and somewhere in these 1,000 files, the attacker’s scripts are hidden!

How realistic is this attack scenario?
What would be the worst-case scenario?

2

Yes if youre qube has been hacked, hacker can modify ANY program in hacked qube
You can move youre files to network air gapped qube, and don`t run any scripts from hacked qube
Hacker by example can infect using unicode hideen symbols all executable code in you data

1 Like
3

Just restart the AppVm.
That is the beauty of QubesOS. If you get compromised, you restart the AppVm and all system files are pulled from the template.
You’d only need to check the files in /home/user

1 Like
4

AppVm are immutable.

5

Surely this is simply false. All AppVM have persistent /rw directory.

Maybe you are confusing with DispVM?

5 Likes
6

I’d go a step further.. Do not start that thing anymore, attach the LVM with the /home to another VM (not sure how in commands but sure its possible), mount it very securely (noexec and bla), extract the data you need to another (disposable) VM where you install security-check tooling, inspect the extracted data for malware and alike, and then copy the data to your new VM where you use it again.

I wouldn’t trust that AppVM anymore, it still has persistent data, even if qvm-move would be restored from the trusted template… I’d consider all data in the AppVM persistent storage to be compromised until confirmed clean.

4 Likes
7

Yes you can`t modify root partition in AppVM, but appvms has so lot methods to modify root on the fly, like rc.local .bashrc bind mounts, and more

2 Likes
8

Good advice!

My “panic actions” -if I suspected a bad qube-would be:

  1. Write down the name of the BADQUBE
  2. qvm-kill
  3. Set netvm of BADQUBE to “None”
  4. Do what @kuhbs said, but only copy the data to a new qube. Set netvm to “None”. Do not mix the BADQUBE data with clean data.
  5. Verify all other qubes for data from BADQUBE inside QubesIncoming directory. Check file dates against last known good date.
  6. Do not trust any data in that new qube.
  7. Best: copy the data to a removable storage, and look at it in a separate, airgapped PC with no persistent storage and a live DVD-R operating system.
  8. If not too worried… Do not look at the data in the new qube
  9. Start a new disposable qube, with netvm=“None”, and copy the data to it, for examination.
  10. Ideally, use a new disposable for each file or group of files.
  11. Remember that even documents, pdf, mp3, video files, and many others must be considered as executable files that could contain the attacker’s code.

What did I forget?

2 Likes
9

I’d recommend a memory dump too.. xl or something had a command for it, dont remember rn, but if there is fishy things going on, do a memorydump in dom0 and a forensic analysis on it as well later (before you kill it) - i’m pretty sure you can do a xl pause / qvm-pause BEFORE you do that memory dump as well.

Update: xl dump-core - run that on the paused VM.

I’d recommend writing a script for this, sth like h4x0r-check.sh , which does xl pause (or qvm-pause if you want), xl dump-core, creates a dd image of the LVM of private and root (root the snapshot if its an appvm, bcs you can still use the modified root vm snapshot to see what the malware did there).

Keep in mind that if you have this qvm-volume (or what it was) ephemeral encryption enabled, this might not work, and you have to find the key BEFORE you shutdown the VM - idk how that works, your LLM of choice can find out.

2 Likes
10

I’d go a step further.. Do not start that thing anymore, attach the LVM with the /home to another VM (not sure how in commands but sure its possible), mount it very securely (noexec and bla)
[… 16 lines elided]

I think qvm-console-dispvm is a good tool for this job.

1 Like
11

for what exactly?

12

Thank you for all the replies.

But my question specifically concerns qvm-move/qvm-copy.
If compromised files are moved to another VM using these commands.
As far as I know, an attacker’s script can be copied, but it won’t run on the new AppVM unless I accidentally launch it myself.
Or is this AppVM already compromised and specifically looking for this new script to execute.

13

Correct, unless there is something parsing them automatically, such as GNOME tracker miner that they renamed for the 3rd time to something else. By default, Qubes disables that and the default template is Xfce nowadays.

Correct, unless there is something parsing them automatically,

And it bypasses several security checks done by qvm-(copy|move) to assert that the file is sane. So no, don’t assume copy can compromise the target. In fact, it is much safer to use qvm-copy than other copying methods, such as rsync, sftp, syncthing or whatever.

4 Likes
14

I don’t see any security checks in the source code of /usr/bin/qvm-copy
Here is the relevant code from the file:

if FILECOPY_TOTAL_BYTES=$(/usr/lib/qubes/qubes-fs-tree-check \
    ${ignore_symlinks} \
    --allow-symlinks --allow-directories --machine -- "${SOURCE[@]}"); then
    service=qubes.Filecopy
else
    status=$?
    if [[ "$status" -ne 2 ]]; then exit "$status"; fi
    service=qubes.Filecopy+allow-all-names
fi
if [[ "$PROGRESS_TYPE" = 'console' ]]; then export FILECOPY_TOTAL_BYTES; fi

/usr/lib/qubes/qrexec-client-vm --filter-escape-chars-stderr -- "$VM" \
    "$service" /usr/lib/qubes/qfile-agent ${ignore_symlinks} -- "${SOURCE[@]}"
1 Like
15

It doesn’t make sense to be on the client, because it could use a variant of qvm-copy instead of /usr/bin/qvm-copy. The checks are made on the server.

1 Like
16

Although those only check that file names stay within a certain set of characters, and (edit: this filename character check is off by default) that any symlinks copied don’t point outside the ~/QubesIncoming/senderVM/ directory. Other than that, a malicious sender VM can send whatever it wants, with arbitrary changes to file content or with added/omitted files.

2 Likes
17

Immutable distros, like SteamOS, are setup that way, Persistent system files only.
That is what an immutable distro is.

18

Anyway, a regular AppVM it not immutable in the sense of a security feature against persistance of malicious code. For example:

echo 'qvm-copy() { bc -l; }' >> ~/.bashrc

This will cause running qvm-copy from an interactive Bash shell to open a calculator instead.

4 Likes
19

I don’t get the discussion. If the VM (regardless of which type) is compromised, you do not trust ANYTHING inside of it.

1 Like
20

You trying to say that a malicious virus can also infect personal files? Yes, that is expected.

I really don’t get what this post is about!
AppVm are immutable. Which means that all you have to do is restart the VM. Personal files might still get infected.

This is a selling point for QubesOS, that is not easy to get hacked.

2 Likes