This vulnerability is not exploitable for VM escape.
The attack works roughly in the following way:
- The attacker creates a malicious GDT at offset 0.
- The attacker remaps the APIC MMIO region to the SMRAM by modifying the IA32_APIC_BASE MSR. This "overwrites" the SMM's DSC structure, which is used by the SMI handler to restore SMM GDT.
- When an SMI happens, the SMI handler will use the malicious GDT, so the control flow can be hijacked.
The bottom line is that this type of attack is feasible only when the attacker can control the IA32_APIC_BASE MSR.
Assuming you run "hardware supported" VMs (VMX non-root mode), an attempt to write an MSR from a VM will generally cause a VM exit, which will be handled by the VMM. The "normal" way of handling an APIC MMIO remap is to either ignore it, or emulate the remapping in the VMM, but this will not cause host's APIC range to be remapped.
The only exception I can think of is when the VMM uses MSR bitmaps (which can be used to "whitelist" certain MSRs to not to cause VM exits), and it somehow incorrectly calculates that bitmap (maybe in the process of merging MSR bitmaps when using nested virtualisation) in a way that allows guests to modify IA32_APIC_BASE, but that would be a vulnerability of the VMM itself.
That being said, this vulnerability can still be useful for post-exploitation: if your VMM gets compromised, the attacker can use it to bypass TXT or install a very-hard-to-detect rootkit.
is there any way to prevent this vulnerability from being exploited?
Actually, one way is to use virtualisation, or you can wait for an official patch (Intel is said to be working on it).
Jacob Torrey also has an interesting blogpost about this topic: