HulaHoop via Whonix Forum:
Whoops. OK this only concerns: Host compromise and/or Gateway comrpomise whcih can then root the host since it is part of the TCB and can access host services without firewall protection thru NAT networking. That is the situation to non-Qubes Whonix at least.
No, it can’t access any host services. VM breakout exploit required.
It’s a reasonable compromise to sometimes consider a Whonix-Workstation
compromised but nothing else.
What about Qubes?
Same from theoretic point of view but much stronger separation by
virtualizer. So no different documentation required regarding various
levels of compromise.
Good point. Do you know how this is done?
Malware is just a program that can do whatever it wants. There could be
a logic “if my runtime after start on this machine is low (so probably
shutdown after infection) do more damage by deleting files”. Or another
logic “if not internet access for too long, start deleting files”.
It will involve connecting the device though. So is not mounting it enough?
Mounting is for sure far safer than booting.
Yes. Was this not clear? It shouldn’t propagate if USB redirection is used properly.
I don’t think any users heard of USB redirection. And if that works,
once we consider USB firmware compromise then such a USB controller
would have forever not be connected to any VM or host that isn’t
supposed to be compromised.
The only way USB could be used to take data from a compromised VM is if
provided to a VM as a blockdevice without exposing the USB
controller/firmware like Qubes is doing. But in case of Qubes, no need
for USB, qvm-copy would do.
I guess this is useful if you care about recovering from compromised VMs only, but the easier way for this is to simply transfer the files you care about out thru shared folder and delete it.
Easier yes, but shared folders require the VM to be booted. And booting
a VM is far less secure than mounting.
If booting a VM: make a copy first in case the malware starts to destroy
files. Also disconnect internet from the VM first so the malware cannot
load new modules (with new exploit code) or do other malicious stuff online.
Interesting. Please add. What do you mean by code attachments? Is there an example we can point to?
There’s non-malicious pdf files and malicious pdf files. Any
non-malicious pdf file can be converted into a malicious pdf file by
modifying it. I am calling this sloppy “code attachment”. Perhaps better
“malicious modification”: Pdf readers are known to have sometimes
vulnerabilities reported about them. Maliciously crafted pdf files can
exploit pdf viewers, i.e. execute code even if pdf files shouldn’t
result in code execution.
There’s been also vulnerabilities found in text editors already, perhaps
even in connection with text files. I am not sure it happen in practice
yet or if it happen only on Windows yet. Search engines indicate it
happened in the Windows world. Nevertheless, theoretically it’s
possible. Parsing a pdf file and parsing a text file to show its
contents is basically the same, code parsing data, just that parsing a
pdf file is much more complex. This is because text editors interpret
the contents of text files. The more feature rich the text editor, the
more likely some parsing of the text file can lead to a code execution
vulnerability.
Another example would be cat. There’s been vulnerabilities in
terminal-emulators before. The simplest example of a malicious text file
would be if the victim will use cat on a text file and exploit a new
terminal-emulator vulnerability.
More sophisticated malware is known to infect (make malicious
modifications) to other files so a reinfection is likely once someone
reinstall and then reuses their data. That should be pointed out.
Sanitizing files is not foolproof
Indeed.
and so I consider it out of scope.
I see. Well, I doubt many users who go through the pain of compromise
recovery would go through the pain of trashing all of their data and
starting fresh.
The focus of this guide is to recover VMs. My approach is to consider all VMs and the compromised host hardware as expendable. It is also applicable to more setups/Whonix ports and even systems in general.
We can still mention it for those who want to do the VM recovery approach (Qubes users only)
I don’t think VM recovery is Qubes specific.
