Here’s a list of Frequently Asked Questions and the answers. If you have more questions, you can contact Bromium customer support or leave a comment here on the blog.
Is Bromium isolation affected by the CPU design flaw?
There are two separate vulnerabilities that have been disclosed as part of the ongoing issue. They are named Meltdown and Spectre (https://meltdownattack.com)
Meltdown (Intel Only):
Bromium Isolation is not affected by Meltdown. Meltdown uses the Intel design flaw to bypass the operating system kernel protection which stops applications reading arbitrary parts of memory belonging to other applications or the kernel itself. Because each micro-VM that isolation uses has its own kernel, the Meltdown vulnerability will happen inside the micro-VM but will not allow the malware to access any memory on the host. The host is protected from the Meltdown attack and everything happens inside the micro-VM just as expected with Bromium isolation. Meltdown is not a guest escape mechanism. Other isolation technologies however, such as containers or anything that shares a kernel, are susceptible to this kind of attack.
Spectre uses an architectural flaw common in most modern CPUs to bypass operating system kernel protections. These protections stop applications from reading arbitrary parts of memory belonging to other applications or the kernel itself. This attack is more complex than Meltdown, although it has been demonstrated to be viable under some controlled and limited circumstances.
If Spectre was used by an attacker within a micro-VM container as per Meltdown, the attacker may be able to access memory belonging to the guest kernel. However, since micro-VM guest kernels do not contain sensitive information, this is not a concern.
It is conceivable that an attacker could create a highly targeted version of a Spectre exploit that could attempt to read host memory from inside the guest. This would require a highly specialized attack. Since Spectre is a data leakage vulnerability, escape from a micro-VM could not be achieved directly, but it is conceivable that an attacker might be able to read host memory containing sensitive data that they could then use to compromise the host. We currently believe this attack would create considerable custom effort.
Why is Bromium having to release an update?
Microsoft updated the way Windows (all versions at the time of writing) manages memory to avoid the CPU flaw. It is this change by Microsoft that affects Bromium software.
This change affects all software that makes system calls on Windows. The patch was released earlier than originally planned by Microsoft due to the publicity in international media. It went live for Windows 10 overnight on January 3rd 2018 and is now on Windows Update (The Microsoft Update on patches can be viewed here.) All Windows 10 versions will be updated by Windows Update and will cause compatibility issues with Bromium isolation until Bromium releases the updated 4.0 Update 4 version.
Windows 7 updates are available on the Windows update catalog, but are not yet being pushed by the Windows Update mechanism for Windows 7.
Is only Bromium affected?
No, any software on potentially any version of Windows that makes system calls and makes use of memory management is affected. This will certainly affect other hypervisors, AV, and security software, as well as many desktop applications and other software. The full extent of this change by Microsoft will not be known until users start trying to work as normal and discover which workflows and applications are broken.
What is Bromium doing about it?
Bromium is planning to release a 4.0 Update 4 version of the Bromium Secure Platform to be compatible with the Microsoft patch to address the CPU design flaw. Bromium will be updating customers and partners as soon as the 4.0 Update 4 release of the Bromium Secure Platform is available on https://my.bromium.com for download.
Which versions of Bromium Secure Platform will be updated?
We are focusing on the 4.x version of the Bromium Secure Platform and we expect to release 4.0 Update 4 as soon as possible. If you are still using our legacy product, we strongly recommend that you upgrade to the most recent release – you will immediately gain better performance and a smoother user experience. If that is not possible, we will release a patch for Bromium Advanced Endpoint Security 3.2 at a later date.
Which versions of the operating systems are affected?
All operating systems we know of that utilize Intel CPUs will need to be updated by the OS vendors (Linux, all versions of Windows, and Apple MacOS X x64.) Application vendors will then need to update once they discover incompatibilities with the OS updates.
However, initial testing indicates that only the Windows 10 patch from Microsoft breaks Bromium isolation. While the patch for Windows 7 is available for manual download from the windows catalog, it is not being actively pushed by Windows Update at this time. When manually downloaded and enabled, both Advanced Endpoint Security 3.2 Update 8 and Bromium Secure Platform 4.0 GA Update 3 are able to browse, reinitialize, and browse on Windows 7.
This is based on limited initial testing and will be updated as we learn more.
What can I do to mitigate the issue?
You can opt to stage the Microsoft patch if you currently do so to test your deployment before pushing to your production environment. If you choose to do this, Bromium isolation will continue to work as expected until you roll out the patch. This allows time for you to deploy the 4.0 Update 4 release when it is available, and then push the Microsoft security fix. This is keeping in line with guidance that Microsoft is providing to its customers where AV solutions are currently incompatible with the security patch.
If you do not stage Microsoft patches and allow servers and endpoints to take Windows updates directly when Microsoft pushes them out (especially security patches), you should uninstall the specific KB update from affected endpoints. This allows the existing Bromium Secure Platform version to maintain protection and application isolation until version 4.0 Update 4 is available.
What does an end user experience when the update results in compatibility issues with Bromium?
Endpoints will see the update, reboot (if not already), and Bromium isolation will try to reinitialize. Initialization will fail and the Desktop Console will display the following status:
By default, our product is configured to allow browsing while in this state, using the default configuration of AllowUntrustedAccessDuringInitialization=1. This means users will be able to continue to browse and load documents, but they will NOT be protected by Bromium isolation – the content will load on the host because isolation is unable to start up micro-VMs. This state is reported to the Bromium Controller, where you can view the current levels of protection in your deployment and which endpoints are in conflict with the Microsoft KB.
If this configuration has been changed, users will no longer be able to browse or load untrusted documents and so on. This is also reported to the controller; however, this has a bigger impact on users.
As mentioned earlier in the FAQ, the recommended method of enablement is to uninstall the KB patch from Microsoft to allow the Bromium Secure Platform to return to its normal functional state. Once version 4.0 Update 4 is available, you can then deploy the Microsoft KB security patch. Reinitialization will be required post install as usual for the Bromium Secure Platform.
How do I uninstall the Microsoft KB to address compatibility issues?
If a machine that has this KB installed reboots, Bromium isolation will subsequently fail to initialize.
The update can be removed. To do this:
- Navigate to Control Panel > Programs > Uninstall a program > View installed updates
- Right-click on the KB and click Uninstall.
Note: There are different KB numbers for different editions of Windows 10, including KB4056890, KB4056891, KB4056892.
Reboot your machine.
Is Bromium affected by the vulnerability as it affects the Xen Hypervisor?
No. The Xen hypervisor (as used in XenServer, AWS and so on) supports two types of guests: Full PV and HVM. Full PV guests are a legacy of Xen’s early days, dating back to the early 2000s when CPUs did not have specialized virtualization extensions such as VT-x (Intel) and AMD-V (AMD). HVM guests are VMs that make full use of the virtualization CPU support. They may contain para-virtual drivers (PV Drivers), but this is distinct from being full PV guests. Use of Full PV has been deprecated for many years by the Xen community, but many cloud providers continued to encourage their use even after they were deprecated as their cloud hardware didn’t support VT-x/AMD-V. Until recently, cloud providers such as AWS supported Full PV for reasons of backward compatibility, enabling older VMs to continue to run.
A HVM guest cannot use the Intel Meltdown vulnerability to attack a Xen host. The isolation provided by the virtualization extensions ensures that host virtual addresses are always kept separate from the guest address space.
Full PV guests use the traditional CPU virtual memory hardware to provide isolation between host and guest. The Intel Meltdown flaw means that the isolation that the CPU is supposed to be providing is violated, and there is the potential for an unprivileged guest to read host memory. As such, Xen suffers in the same way as OSes such as Windows and Linux. To help cloud providers, the Xen community is creating a solution so that Full PV guests can be run inside a containing HVM VM to restore the isolation. This support is yet to be deployed by cloud providers such as AWS, so in the meantime, they have disabled support for Full PV guests.
Bromium products do not use the Xen hypervisor. The development team heritage is such that they share some ideas and code but the Bromium hypervisor is quite different, designed with security as the primary goal. Great pains have been taken to minimize the Bromium hypervisor’s attack surface, so support for legacy features such as Full PV guests did not make sense. Therefore, there is no issue with Meltdown being used to read host memory from a guest running on a Bromium system.
When was the last Intel CPU bug of this magnitude discovered?
The last time something similar to this happened would be the Intel floating point division bug. This impacted Pentium CPUs in the mid 90s and resulted in a mass hardware replacement program. While not security related, it was perceived as having the same severity. For more information, see: https://en.wikipedia.org/wiki/Pentium_FDIV_bug
I’ve heard about impacts to performance over all in the Microsoft fix, is this true?
Yes – initial speculative media and social reports state that there could be anywhere from a 5% to 30% performance hit on various applications and workloads (that utilize the CPU). This is yet to be substantiated and the media are updating reports of various testing as this story unfolds.