"If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle." --- Sun Tzu
Hypervisor is what we called "Ring -1" world and it becomes a very important layer in "cloud"( Someone else's computer?) environment.
- Adventures with a certain Xen vulnerability - 200809
- Xen 0wning Trilogy - 200808, I, II, III
- Attacking Intel® Trusted Execution Technology - 200902
- CLOUDBURST A VMware Guest to Host Escape Story - 200908, paper and video
- IsGameOver(), anyone? - 200708
- Security Challenges in Virtualized Environments - 200804, the slide is here. Neo swallowed the red pill to enter the Nebuchadnezzar battleship and then he figured out that it's just another Matrix.
- Following the White Rabbit: Software Attacks against Intel® VT-d - 201105
- Advanced Exploitation of Xen Hypervisor Sysret VM Escape - 2012
- CAIN: Silently Breaking ASLR in the Cloud
- Adventures in Xen exploitation - 201502
- Xen SMEP (and SMAP) bypass Introduction - 201504
- VENOM, CVE-2015-3456 - 201505
- VM escape: QEMU Case Study - 201704
- Attacking a co-hosted VM: A hacker, a hammer and two memory modules
- Sicherheitsanalyse KVM (Kernel-based Virtual Machine)
- Xenpwn, toolkit for memory access tracing using hardware assisted virtualization.
- guestrace
- Qubes OS
- IOMMU( Intel vt-d)
- Restrict on /dev/mem
- Audit open() syscall with O_DIRECT
- ret2usr protection
- PaX's KERNEXEC stuff, RO for the memory areas that doesn't need write & NX on the most memory maps
- check few possible backdoor implanted funcs: IDT, hypercall_table, exception_table
- No selft-modifying code in hypervisor, code diversification won't work?
- Block all accesses from guest vm to host I/O ports
- KSM: perf trade-off
- Proper entropy bits to aginst brute-force
Using VirtualBox is STRONGLY DISCOURAGED, you should switch to a Xen or KVM-based virtualization.
VirtualBox depends on its kernel moudule to function properly, but the module failed to adopt state-of-art security measures. VirtualBox doesn't support KERNEXEC, UDEREF, RANDKSTACK, or SMAP, as spender once said.
This will be reverted once the VirtualBox devs stop disabling SMAP unnecessarily, which seems like it will happen never. Anyone who cares about security of their host system shouldn't use VirtualBox, as it already precludes the use of KERNEXEC, UDEREF, and RANDKSTACK.
Xen is one of the earliest technology for virtualization for Linux kernel, it has many undesirable designs in a security-oriented perspective. Instead of separating or isolating different components, it uses a monolithic and complicated architecture. Any bugs in Dom0 could easily lead to the compromise of the entire system.
Dozens of critical vulnerabilities are discovered from Xen, about one to three each year, allowing the Guest to subvert the Host entirely. KVM is not fundamentally more secure than Xen, but has apparently somehow comes with less vulnerabilities.
See this paper.
Sometimes, it's still desirable to use Xen. KVM is a Type-II hypervisor, which is simply a module runs under the "big and fat" Linux kernel, while Xen is a true bare-metal Type-I hypervisor, contains nothing but the hypervisor itself. Although in practice Dom0 always uses Linux kernel, Xen still presents smaller attack surface as a hypervisor.
See Qubes OS Architecture, 3.2. Xen vs. KVM security architecture comparison, to see if Xen better suits your use case.
(TODO: more citations)