27

Avast antivirus has an option for disabling "Enable hardware-assisted virtualization". If it's enabled, how is it a security issue?

Ruslan
  • 247
  • 2
  • 7
hyperscience
  • 389
  • 1
  • 3
  • 5
  • 4
    tl;dr disabling this won't improve security, and might actually make it worse. – forest Dec 26 '19 at 03:52
  • 2
    Isn't the risk not that hypervisor rootkits are possible, but that there might be a yet-unknown vulnerability in a microprocessor's hardware virtualization functionality (like Spectre or Meltdown)? In which case, keep it enabled until someone claims there's a threat that can be mitigated by disabling it? – Dai Dec 26 '19 at 13:06
  • 2
    @TheD It already requires ring 0, so that's not really an issue. – forest Dec 27 '19 at 08:16

4 Answers4

37

My research suggests that you have misinterpreted the meaning of the setting, e.g., see this thread.

Avast is capable of using hardware-assisted virtualization to provide better anti-virus protection. However, because this can cause compatibility issues with other software, an option is provided to disable this functionality.

That is, if you turn off the "Enable hardware assisted virtualization" you are not telling Avast to disable hardware virtualization on the PC; rather, you are telling Avast not make use of the hardware virtualization functionality itself.

Harry Johnston
  • 1,667
  • 10
  • 14
  • 8
    Interesting! This makes a lot more sense. I hope OP accepts this answer. – forest Dec 27 '19 at 09:22
  • 3
    It may be worth noting for OP that if you _did_ want to disable the virtualisation capability, thats not for the OS to decide and you would change this in the BIOS. As the other answer by forest states, it's commonly referred to as VT-x or AMD-V in BIOS should you wish to disable it. Doing so won't make a difference to your use case unless you virtualise machines, but if it will give you peace of mind then go for it. – QuickishFM Dec 27 '19 at 22:34
  • 1
    How exactly could an Anti-virus software benefit from virtualisation? – Alexander Dec 28 '19 at 16:12
  • 1
    @Alexander-ReinstateMonica Good question, might warrant its own Q&A thread. I have some suspicions how it could speed-up the threat-detection, but nothing close to definitive. – Mast Dec 28 '19 at 17:42
  • 1
    @Alexander, all I've been able to find on that subject is the one feature, [Safe Zone](https://www.pcworld.com/article/220255/avast_antivirus_6_combats_trojans_with_virtualization.html) that provides the user with access to a browser running in a separate VM to "combat keyloggers and spyware". According to that article, "The company is confident the feature will work even if the machine has been infected prior to installation." (Personally I'm dubious.) This might not be the only functionality in Avast that uses virtualization, but it's the only one I could easily find. – Harry Johnston Dec 28 '19 at 22:53
  • @Mast I'm not sure what I would be asking. My phrasing as-is seems broad, and is asserting a premise I'm not even sure of. But "Could anti-virus software benefit from virtualisation (at all)?" is *even more* broad. – Alexander Dec 31 '19 at 22:45
27

In theory, hardware-assisted virtualization can make hypervisor-based rootkits possible. However, this type of malware already requires extremely high privileges and is not a particular threat. Furthermore, hardware-assisted virtualization can be used by Windows to supplement its sandbox for added security. It's not a security issue so much as a feature optionally used by one theoretical kind of malware.

A hypervisor is software which is able to run a virtual operating system underneath it. The hypervisor, in other words, pretends to be real hardware so the operating system running under it doesn't need to be aware of this fact. Hardware-assisted virtualization (called VT-x for Intel and AMD-V for AMD) is simply a CPU feature that allows hypervisors to run at native performance, as if the hypervisor wasn't there.

You will not improve security by disabling hardware-assisted virtualization. Because it requires such high privileges to use in the first place, any malware that is able to use it is already able to bypass any restrictions you set. As such, Avast's option to disable this feature provides no additional security, and might actually decrease security by preventing Windows from using it in its HyperV-based sandbox.

forest
  • 64,616
  • 20
  • 206
  • 257
  • 1
    It begs the question (although not fit for this particular Q&A exchange) on why Avast even bothers putting that option on their software. Surely one can assume they know it is just glitter. – Mindwin Dec 26 '19 at 16:47
  • 14
    @Mindwin glitter sells products – Richard Tingle Dec 26 '19 at 17:07
  • 3
    @RichardTingle I think it's more 'tradition' at this point. Windows used to not take advantage of hardware virtualization for any security features, and thus it literally was just yet another way malware could make itself hard to remove for anybody who was not doing any type of virtualization (or playing games that use one of the anti-cheat rootkits that use it). – Austin Hemmelgarn Dec 26 '19 at 19:41
  • 2
    @RichardTingle Agreed. They can put a nice checkmark next to "prevents against hypervisor rootkits and virtualization attacks" on their product feature matrix and perhaps their more sensible competitors can't. – David Schwartz Dec 27 '19 at 08:27
  • 2
    I don't think that's what the option does, see [my answer](https://security.stackexchange.com/a/223298/47469). – Harry Johnston Dec 27 '19 at 09:18
2

VT can be an issue, because of improper guest-isolation, where data from one VM can leak to another VM. See L1TF - L1 Terminal Fault for affected CPU and possible migitation approaches. While those containers are all under your control, the attack vector is rather theoretical.

But one certainly cannot disable VT from within the OS. Avast AntiVirus may have it's own sand-boxed container, which may either run hardware-accelerated or not. This likely affects it's startup speed and also the resource utilization, but it has no direct security implications. Searches alike site:forum.avast.com virtualization hint for possible interference with other VM. Therefore, while there is no interference with other virtual machines (depending which type of hyper-visor they use) and VTx is enabled in the BIOS, one should enable hardware-acceleration for Avast. This setting is generally all about using a type I vs. a type II hyper-visor for that sand-boxed container.

-2

Virtualization Technology allows running an operating system in a fully sandboxed virtual computer, and even allows exposing a different CPU type and different CPU capabilities to the OS, to the extent that it is possible to simulate a CPU that isn't virtualization capable, and that itself looks and behaves like a physical CPU.

This way, it is possible to install malware that encapsulates the OS completely and thus can hide from scanners. The only difference you'd see, if you took the care to look, was a slight difference in reserved memory at startup compared to an uncompromised system, and that the CPU does no longer present VT interfaces to the OS.

Unless you are running virtual machines yourself, you wouldn't notice, so the BIOS allows disabling VT at first boot, so it is no longer possible for a virus to hide behind VT. To reenable VT, the CPU needs to be properly power-cycled, not just reset, so this setting can only be changed from the Setup, and ideally the power cycle would need manual input as well -- older machines would power down after changing the setting and require the user to press the power button again.

As a user you would leave this setting disabled until you explicitly require it. It's part of malware protection, not even a particularly good one, but one additional hoop that malware authors have to jump through, and the usual cynical approach to security applies: the zebra doesn't have to run faster than the lion, just faster than the slowest other zebra -- if infecting your computer is more effort than infecting a few thousand others, most attackers won't bother.

Simon Richter
  • 1,482
  • 11
  • 8
  • 2
    That's a pretty crazy attack. Running P2V on the host and then booting to your virtual container? Do you have any examples of code that does this in the wild? It sounds like something that would be, slow, prone to failure, require multiple reboots, and generally be easy to detect. – HackSlash Dec 27 '19 at 00:01
  • 1
    @HackSlash, the goal here isn't to attack the system, but to remain undetected after successful takeover. It is trivial to set up a 1:1 mapping for physical memory and exceptions for a running OS, then activate the virtualization extensions -- interrupt overhead goes up a bit, but that's it. This gives your malware CPU control at regular intervals, invisible to the host OS, and also gives you control when the CPU goes idle -- which gives you ample time to scan memory contents for something interesting. You don't want or need a full hypervisor here, just the bare minimum. – Simon Richter Dec 27 '19 at 09:53
  • 4
    @SimonRichter Although that is possible, any malicious process doing that must be in CPL0, which already gives it enough capability to persist or remain undetected. – forest Dec 27 '19 at 10:16
  • 1
    _and that the CPU does no longer present VT interfaces to the OS_ – Well, at least if nested VT isn't supported. – forest Dec 27 '19 at 11:57