There’s a new VirtualBox bug report, about ability of attacker to replace the Vbox firmware. The bug report had a link to a zipped DOCX file. It appears, from Oracle’s response, that they consider firmware root-of-trust a future enhancement, not a current bug. Virtualized firmware is interesting for attackers with OS root access: in that the firmware is more accessable, it is merely files on a disk, instead of flash-based, not just the files on the ESP.
This issue was initially reported to the security team, but after some discussion it was mentioned that I should open this in the public bug tracking system (seems strange to me, but…). Just for reference, follow the final conclusion from the security team:
“Admin rights give a user the power to do anything on the system. An “evil admin” is more a social component of this bug than a product’s security abilities (or its lack thereof). However, we get your point and think that the “validation/check” proposed by you may be an enhancement feature in the product. Since our team (SecAlert) only deals with security vulnerabilities in the product, we will not be able to help you on this further. You could log an enhancement request on VirtualBox’s public bug tracker: https://www.virtualbox.org/wiki/Bugtracker “
[…]What we will target:
– DMI Information;
– IDE/AHCI devices (harddisks, cd-rom’s);
– ACPI OEM Information;
– Ethernet Adapter MAC address;
– PXE Boot data;
– ACPI DSDT (Differentiated System Description Table);
– ACPI SSDT (Secondary System Descriptor Table);
– VGA Video BIOS data;
– BIOS data;
– VM splashscreen (optional, just for nice looking).
It requires Visual Studio and only targets Microsoft Windows. No Linux, FreeBSD, Mac OS X support. 😦
Somewhat related, there are also these 2 projects:
There’s another new Github project related to UEFI, this one is a turorial using UEFI undre VirtualBox. Most use of virtualized UEFI occurs under QEMU, but VirtualBox also supports UEFI’s OVMF (Open Virtual Machine Firmware) format, so it is nice to see more documentation on using UEFI with VirtualBox, not only QEMU.
Tutorial on making UEFI with CMake and VirtualBox
UEFI Bare Bone Exercise
by Emanuele Ruffaldi using CMake,mxe and VirtualBox/Qemu
Related instructiosn from OSDEV: http://wiki.osdev.org/UEFI_Bare_Bones Other related project (Make+QEmu): – https://github.com/tqh/efi-example – http://www.rodsbooks.com/efi-programming/hello.html
* GCC Cross Compiler x86_64-w64-mingw32. MXE is fine
If you do Windows kernel debugging in VMWare/VirtualBox VMs, and don’t know about VirtualKD, this will be exciting for you:
“VirtualBox Hardened VM detection mitigation loader: VBoxAntiVMDetectHardened is a complex of methods implemented to reduce VM detection possibilities of the common malware.”
Interesting, there are UEFI patches for this, as well!
A few days ago Oracle released a new version of VirtualBox. It is a maintenance release, no huge new features I noticed, but lots of bugfixes, many related to hardware security issues, though no CVEs that I noticed.
Oracle relased version 5.0 of VirtualBox yesterday. I don’t see any firmware features listed in the press, and I’ve not had a chance to do a code review of the new code yet. It has improved CPU and USB 3.0 support, at minimum.
QEMU is the main platform for running UEFI’s virtual firmware: OVMF. But Xen, KVM, and VirtualBox also support OVMF, to some degree. VirtualBox can also be recompiled with EFI-specific build directives to enable additional UEFI diagnostics.
(In somewhat related news, back in March, Oracle’s Linux distro got Secure Boot support.)
As reported by Robert Hackett at Fortune, Crowdstrike has research on a new vulnerability that impacts virtualization. Venom stands for “virtualized environment neglected operations manipulation”. It impacts QEMU, Xen, KVM, and VirtualBox, among others.
(It must be a big deal, as it already has an icon. I think Heartbleed took longer for it’s icon.)