0

I'd like to know how much the risk changes if I don't update the software on the guest OS in a VM (applications and the guest operating system itself), compared to the risk in case it's all kept up-to-date.

NOTE: The guest OS in the VM can potentially be used for any purpose, but in this case let's say the main purpose of a VM is to avoid infecting the host OS, and therefore the VM will be used to run untrusted applications, open untrusted files (pdf, doc, html, etc.), maybe visit untrusted websites, etc. So yeah, I'm not using a VM just to visit youtube, in that case the risk will probably be negligible in any case (whether the system is up-to-date or not). I'm thinking of VMs for more risky stuff.

I'm asking this question because I realized that it can be a pain to keep the software in a VM up-to-date, especially when you have several VMs, or when you only want to use disposable instances, or when you don't want the network to be available in VMs, or when you rely on snapshots (which will then be older and therefore out-of-date). I know that not keeping it up-to-date is likely to increase the risk, but I don't know how much, and for all I know the difference could even be negligible. It probably depends on the likelihood of escaping from a VM by exploiting a vulnerability in the VM itself without relying on any other vulnerability in the guest OS, compared to the probability that a vulnerability in the guest OS is needed in order to escape from the VM. So maybe only somebody with enough experience on VM vulnerabilities could be able to assess the likelihood of this risk.

reed
  • 15,398
  • 6
  • 43
  • 64
  • @SteffenUllrich, I'm just interested in the risk of infecting the host OS though through the VM, not the guest OS, so I don't care if the guest OS is taken over. However, you are right when you say it depends, because now that I think of it the risk can vary in different ways depending on the exact scenario. I'll add a few details. – reed Sep 18 '18 at 18:35

2 Answers2

2

Of course, the chances of malware being able to even attempt escaping without first exploiting a vulnerability in the Guest OS are next to none in most use cases. Therefore, it technically does increase the chances of you getting infected.

On the other hand, VMs are often used even for malware research, where the guest OS is intentionally infected and the VM used to protect the Host OS. In my opinion, it is safe enough to rely on a reliable up-to-date and well configured VM to protect your host OS.

Keep in mind however, that having the Guest OS infected may cause more trouble than just infecting your host OS. It may start acting as part of botnet, it may be used as stepping stone to breach your network, to mine crypto-currencies and in a variety of other annoying and potentially dangerous ways.

Peter Harmann
  • 7,728
  • 5
  • 20
  • 28
1

Based on your question it must be assumed that it is possible for the attacker to fully take over the VM. When this is done there are several ways for the attacker to cause harm against the host OS or even further:

  • There were several bugs in the past which allowed an attacker to cross the virtualization boundary and execute code inside the host OS from inside the VM. Given that virtualization is typically run with system privileges, breaking out of the VM gives the attacker direct root access in the host OS. This can mostly be prevented by using up-to-date virtualization software.
  • If the VM has network access it might attack networked systems outside the VM, for example access some network accessible configuration tool in the host OS or use DOS attacks against machines reachable from inside the VM, send spam or similar. This can be prevented with completely denying any network access (i.e. no virtual network cards) or using restricted networking (host-only networks, firewalls etc).
Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • On your point 1, I don't think modern Hyper-visors have these vulnerability.... Any thought around this...? – Kay Sep 19 '18 at 08:19
  • @Kay: Just a short look at CVE for [vmware](https://www.cvedetails.com/vulnerability-list/vendor_id-252/Vmware.html) or [Xen](https://www.cvedetails.com/vulnerability-list/vendor_id-6276/XEN.html) shows several critical vulnerabilities in 2017 which might result in code execution in the host OS. – Steffen Ullrich Sep 19 '18 at 08:27