Virtualization Security

• Microsoft fixes Hyper-V bug in Windows

Guests on a Hyper-V system could trigger the flaw in the CPU chip set to issue instructions that could place the host system into a nonresponsive state, resulting in a denial-of-service condition for guest operating systems. The attacker would have to first secure kernel-mode code execution privileges on the guest operating system in order to trigger this denial-of-service condition.
Unlike Xen and VMware, Hyper-V functions only on systems with hardware support for virtualization, such as servers with Intel VT-x and AMD-V hardware virtualization extensions. As a result, Hyper-V is typically not at risk for escape attacks, where the attackers target the guest system in order to compromise the host.
http://www.infoworld.com/article/3005238/security/microsoft-fixes-hyper-v-bug-in-windows.html

• Common Virtualization Vulnerabilities and How to Mitigate Risks

VM escape:A guest OS escapes from its VM encapsulation to interact directly with the hypervisor.This gives the attacker access to all VMs and, if guest privileges are high enough, the host machine as well. Although few if any instances are known, experts consider VM escape to be the most serious threat to VM security.

How to Mitigate Risk
VM traffic monitoring:The ability to monitor VM backbone network traffic is critical.Conventional methods will not detect VM traffic because it is controlled by internal soft switches.However, hypervisors have effective monitoring tools that should be enabled and tested.
https://pentestlab.wordpress.com/2013/02/25/common-virtualization-vulnerabilities-and-how-to-mitigate-risks/

• Top Virtualization Security Mistakes (and How to Avoid Them)

Mistake #1: Misconfiguring virtual hosting platforms, guests, and networks
Mistake #2: Failure to properly separate duties and deploy least privilege controls
Mistake #3: Failure to integrate into change/lifecycle management
Mistake #4: Failure to educate other groups, particularly risk management and compliance staff 
Mistake #5: Lack of availability or integration with existing tools and policies
Mistake #6: Lack VM visibility across the enterprise
Mistake #7: Failure to work with an open ecosystem
Mistake #8: Failure to coordinate policy between virtual machines and network connections   
Mistake #9: Failure to consider hidden costs
Mistake #10: Failure to consider user-installed VMs
https://www.sans.org/reading-room/whitepapers/analyst/top-virtualization-security-mistakes-and-avoid-them-34800

• Kernel exploits

Unlike in a VM, the kernel is shared among all containers and the host, magnifying the importance of any vulnerabilities present in the kernel. Should a container cause a kernel panic, it will take down the whole host. In VMs, the situation is much better: an attacker would have to route an attack through both the VM kernel and the hypervisor before being able to touch the host kernel.
Denial-of-service attacks
If one container can monopolize access to certain resources–including memory and more esoteric resources such as user IDs (UIDs)—it can starve out other containers on the host, resulting in a denial-of-service (DoS), whereby legitimate users are unable to access part or all of the system.
Container breakouts
By default, users are not namespaced, so any process that breaks out of the container will have the same privileges on the host as it did in the container; if you were root in the container, you will be root on the host.2 This also means that you need to worry about potential privilege escalation attacks–whereby a user gains elevated privileges such as those of the root user, often through a bug in application code that needs to run with extra privileges.
Poisoned images
If an attacker can trick you into running his image, both the host and your data are at risk. Similarly, you want to be sure that the images you are running are up-to-date and do not contain versions of software with known vulnerabilities.
https://www.oreilly.com/ideas/five-security-concerns-when-using-docker