The macOS EFI Unlocker removes the check for server versions of Mac OS X verisons:
* 10.5 Leopard
* 10.6 Snow Leopard
allowing the non-server versions of Mac OS X to be run with VMware products. Later versions of Mac OS X and macOS
do not need the modified firmware due to Apple removing the restrictions imposed on 10.5 and 10.6.
EFI Unlocker 1 is designed for the following products:
* VMware Workstation and Player versions 14/15
* VMware Fusion versions 10/11
The checks for the server versions are done in VMware’s virtual EFI firmware and looks for a file called
ServerVersion.plist in the installation media and the installed OS. The patch modifies the firmware to check
for a file present on all versions of Mac OS X called SystemVersion.plist.
The patch uses a tool called UEFIPatch to make the modifications.
Please note you may need to use macOS Unlocker version 3 to run on non-Apple hardware.
The National Cybersecurity Center of Excellence (NCCoE) at NIST recognizes the need to address security and privacy challenges for the use of shared cloud services in hybrid cloud architectures, and has launched this project. This project is using commercially available technologies to develop a cybersecurity reference design that can be implemented to increase security and privacy for cloud workloads on hybrid cloud platforms. This project will demonstrate how the implementation and use of trusted compute pools not only will provide assurance that workloads in the cloud are running on trusted hardware and are in a trusted geolocation, but also will improve the protections for the data within workloads and flowing between workloads. This project will result in a NIST Cybersecurity Practice Guide—a publicly available description of the solution and practical steps needed to implement a cybersecurity reference design that addresses this challenge.
Step by step guide for how to build your own PXE boot server supporting both legacy BIOS and EFI hardare
Build your own PXE boot server
This article is a step by step guide for building your own PXE boot infrastructure which can be used to boot both legacy BIOS and EFI based hardware from network. There are many articles on the Internet for building PXE boot infrastructure however I found most of them does not work for EFI based hardware. I use iPXE as the boot image and dnsmasq as DHCP & TFTP server and I found it’s dead simple to setup those two software.
I believe this is a new (or revised) document [to me].
[…]VMware Tools version 10.1 or later is required for virtual machines that use UEFI secure boot. You can upgrade those virtual machines to a later version of VMware Tools when it becomes available.
For Linux virtual machines, VMware Host-Guest Filesystem is not supported in secure boot mode. Remove VMware Host-Guest Filesystem from VMware Tools before you enable secure boot.[…]
Introducing support for Virtualization Based Security and Credential Guard in vSphere 6.7
Microsoft virtualization-based security, also known as “VBS”, is a feature of the Windows 10 and Windows Server 2016 operating systems. It uses hardware and software virtualization to enhance Windows system security by creating an isolated, hypervisor-restricted, specialized subsystem. Starting with vSphere 6.7, you can now enable Microsoft (VBS) on supported Windows guest operating systems. You may or may not be familiar with these new Windows features. Based on conversations I have with security teams, you might want to become familiar! What you will hear first and foremost is the requirement for “Credential Guard” which is why I added that to the title. In order to level set the conversation in this blog I will go over the features as they related to a bare metal installation of Windows and then a Windows VM on ESXi.[…]
Identifying ESXi boot method & boot device
Posted on 01/09/2018 by William Lam
There was an interesting discussion on our internal Socialcast platform last week on figuring out how an ESXi host is booted up whether it is from local device like a disk or USB device, Auto Deploy or even boot from SAN along with its respective boot device? Although I had answered the question, I was not confident that we actually had a reliable and programmatic method for identifying all the different ESXi boot methods, which of course piqued my interest. With a bit of trial and error in the lab, I believe I have found a method in which we can identify the ESXi boot type (Local, Stateless, Stateless Caching, Stateful or Boot from SAN) along with some additional details pertaining to the boot device. To demonstrate this, I have created the following PowerCLI script ESXiBootDevice.ps1 which contains a function called Get-ESXiBootDevice.[…]
[…]Workstation 14 Pro builds from the newest vSphere Virtual Hardware Platform, now at version 14, and with it delivers new features such as support for:
– Microsoft Device Guard and Credential Guard “Virtualization Based Security” feature support for Windows 10 Guests (Guests only at this time)
– A new Virtual NVMe device for faster disk access on SSD storage and a requirement for vSAN testing
– UEFI Secure Boot, required for VBS and supported with ESXi 6.5 Virtual Guests.
– A new Virtual Trusted Platform Module which is used to manage keys for guest encryption services such as BitLocker.
– Support for the latest Intel Kabylake and AMD Ryzen CPUs
Barrelfish is a new research operating system being built from scratch and released by ETH Zurich in Switzerland, originally in collaboration with Microsoft Research and now partly supported by HP Enterprise Labs, Huawei, Cisco, Oracle, and VMware. […]
Hagfish is the Barrelfish/ARMv8 UEFI loader prototype: Hagfish (it’s a basal chordate i.e. something like the ancestor of all fishes). Hagfish is a second-stage bootloader for Barrelfish on UEFI platforms, most importantly the ARMv8 server platform. […]
Secure Boot for ESXi 6.5 – Hypervisor Assurance
I’ve talked about how vSphere has been moving towards a “secure by default” stance over the past few years. This can clearly be seen in the new vSphere 6.5 Security Configuration Guide where the number of “hardening” steps are growing smaller with every release. In this blog post we will go over another “secure by default” feature of vSphere 6.5 that provides hypervisor assurance, Secure Boot for ESXi. One of the coolest things in 6.5, in my opinion, is the adoption of Secure Boot for ESXi. Now, you might say “But my laptop has had Secure Boot since Windows 8, what’s the big deal?” Well, the “big deal” is that we’ve gone beyond the default behavior of Secure Boot and we now leverage the capabilities of the UEFI firmware to ensure that ESXi not only boots with a signed bootloader validated by the host firmware but that it also ensures that unsigned code won’t run on the hypervisor. Best of all, it’s simple to implement! Let’s dive in![…]
Stephen J. Bigelow has an article in TechTarget.com on VMWare and Secure Boot:
VMware vSphere 6.5 takes an extra security step, building on UEFI secure boot with added cryptographic validation to all ESXi components. VMware vSphere 6.5 added numerous features designed to improve the security of virtual machines both at rest and…[…]
You’ll have to give TechTarget.com your email address to read the article. 😦
Tom Fenton has an article in Virtualization Review on the latest version of VMWare’s vSphere 6.5, and this release includes UEFI changes:
[…]Another major security upgrade in this release is “Secure Boot,” to prevent unauthorized operating systems and software from loading during the startup process. Secure Boot is a feature enabled by UEFI, and can be used not only when booting the hypervisor, but also when booting up the guests. VMware has also updated its logging to include the ability to track who did what on a vSphere system. […]
The earlier post on this was when the project was a new project with no code. They have code now, which consists of a few shell scripts and a patch to linux/driver.c. Presume this is unofficial. 🙂
“This is a program to patch VMware Workstation 12 kernel modules and to sign them using a X.509 key and enrolling the key in the system UEFI firmware.”
This project just got created on Github. No code yet, but only an hour old. If you are into VMware and UEFI, you might want to watch for this project to evolve.
VMware Workstation Kernel Modules Signing Patch
This is a program to patch VMware Workstation 12 kernel modules and to sign them using a X.509 key and enrolling the key in the system UEFI firmware.
VMware ESXi, Fusion, Player, and Workstation updates address important guest privilege escalation vulnerability
VMware Security Advisory
Advisory ID: VMSA-2016-0001
Synopsis: VMware ESXi, Fusion, Player, and Workstation updates address important guest privilege escalation vulnerability
Updated on: 2016-01-07 (Initial Advisory)
CVE numbers: CVE-2015-6933
VMware ESXi 6.0 without patch ESXi600-201512102-SG
VMware ESXi 5.5 without patch ESXi550-201512102-SG
VMware ESXi 5.1 without patch ESXi510-201510102-SG
VMware ESXi 5.0 without patch ESXi500-201510102-SG
VMware Workstation prior to 11.1.2
VMware Player prior to 7.1.2
VMware Fusion prior to 7.1.2
VMware would like to thank Dmitry Janushkevich from the Secunia Research Team for reporting this issue to us.
See full announcement for more information, including patch/workarounds.
If you do Windows kernel debugging in VMWare/VirtualBox VMs, and don’t know about VirtualKD, this will be exciting for you:
Advisory ID: VMSA-2015-0009
Synopsis: VMware product updates address a critical deserialization vulnerability
Updated on: 2015-12-18 (Initial Advisory)
CVE numbers: CVE-2015-6934
VMware product updates address a critical deserialization vulnerability in vRealize Orchestrator 6.x and vCenter Orchestrator 5.x. A deserialization vulnerability involving Apache Commons-collections and a specially constructed chain of classes exists. Successful exploitation could result in remote code execution, with the permissions of the application using the Commons-collections library. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the identifier CVE-2015-6934 to this issue.
Three tweets from William Lam of VMware, with more information about new features (and one limitation) of UEFI, including a useful VMware UEFI article:
Excerpt from article:
For those of you who may not know, UEFI is meant to eventually replace the legacy BIOS firmware. There are many benefits with using UEFI over BIOS, a recent article that does a good job of explaining the differences can be found here. In doing some research and pinging a few of our ESXi experts internally, I found that UEFI PXE boot support is actually possible with ESXi 6.0. Not only is it possible to PXE boot/install ESXi 6.x using UEFI, but the changes in the EFI boot image are also backwards compatible, which means you could potentially PXE boot/install an older release of ESXi.
VMware issued a security advisory for 3 CVEs today:
Excerpt of announcement:
VMware vCenter and ESXi updates address critical security issues.
Advisory ID: VMSA-2015-0007
Updated on: 2015-10-01 (Initial Advisory)
CVE numbers: CVE-2015-5177 CVE-2015-2342 CVE-2015-1047
1) VMware ESXi contains a double free flaw in OpenSLP’s SLPDProcessMessage() function. Exploitation of this issue may allow an unauthenticated attacker to execute code remotely on the ESXi host. VMware would like to thank Qinghao Tang of QIHU 360 for reporting this issue to us.
2) VMware vCenter Server contains a remotely accessible JMX RMI service that is not securely configured. An unauthenticated remote attacker that is able to connect to the service may be able use it to execute arbitrary code on the vCenter server. VMware would like to thank Doug McLeod of 7 Elements Ltd and an anonymous researcher working through HP’s Zero Day Initiative for reporting this issue to us.
3) VMware vCenter Server does not properly sanitize long heartbeat messages. Exploitation of this issue may allow an unauthenticated attacker to create a denial-of-service condition in the vpxd service. VMware would like to thank the Google Security Team for reporting this issue to us.
VMWare hasn’t had a security update in a few months, and broke that record today:
VMware vCenter Server updates address a LDAP certificate validation issue
VMware Security Advisory
Advisory ID: VMSA-2015-0006
Synopsis: VMware vCenter Server updates address a LDAP certificate validation issue
Issue date: 2015-09-16
Updated on: 2015-09-16 (Initial Advisory)
CVE numbers: CVE-2015-6932
You must be logged in to post a comment.