Few people would write up a security vulnerability 19 days after it was announced, but in the case of Spectre and Meltdown (CVE-2017-5753, CVE-2017-5715, CVE-2017-5754) each day that we’ve waited has brought new developments and additional information for us to consider, consolidate and present to our customers and blog community.
Readers who follow security news are already aware that the Spectre and Meltdown issues are substantial threats that have severe impacts on security. The vulnerabilities allow processes to read memory information that should not be accessible to them. User processes can access information from other processes and the kernel, in a virtualized environment they can also access information on the host and potentially other guests.
While working to address them be sure not to neglect to apply other patches. Vulnerabilities from last Decembers patches are already being exploited in the wild and, while the impact of Spectre and Meltdown are unique and far-reaching, they ultimately allow attackers the chance to read the information they shouldn’t have access to; remote code execution attacks have a far greater impact.
On servers, a process can access information that they should not have access to. In virtualized environments, this information can come not just from the virtual machine where the process is executing but on the hypervisor and other guests as well. This has the greatest impact on cloud environments followed by internal multitenant environments. The largest cloud environments (Amazon AWS, Azure, and Google Cloud) have implemented patches for these issues on their hypervisors. Unfortunately smaller cloud providers did not receive advanced information about these vulnerabilities and are in various stages of patching. The issues being identified with the patches are also presenting additional challenges as the increase in security is accompanied, in some cases, by stability issues.
For your internal environments, the most significant risks stem from the mixed use of hypervisors. If a machine can execute user-provided code and you do not have the patches in place, then a given virtual machine may be able to access information that should not be visible to it. One of the greatest risk factors we see in enterprise environments outside of the cloud are non-dedicated VDI environments where users virtual machines are mixed with other critical systems on the same servers. Another medium risk factor would be a server running a mixture of Internet-facing DMZ hosts and internal systems. A compromise of a DMZ server could be used to then access information from other virtual servers running on the same host, allowing access to information without needing to compromise other systems in the environment further.
There are some solutions at different levels to the vulnerabilities. To begin with, the issues do not exclusively impact Intel processors, AMD processors and some recent ARM variants are also impacted. OS level fixes are distributed like any other operating system patch. Fixes are available and in various stages of deployment on Windows, Mac OS, Linux, and VMware. iOS has also been patched as well as Google Nexus and Pixel devices running the Android January Security updates. For other Android devices you will need to contact your vendor; the situation regarding Android security updates remains very challenging. There are concerns about the impact of the performance impact of these patches but most workloads are not significantly affected, and you cannot avoid the updates.
Intel was quick to respond and shipped new microcode to address the issues. These fixes can be implemented either through a BIOS update or inside the operating system. Unfortunately, there have been some serious issues with these microcode updates. Some applications are impacted, and increases in server reboots have been reported. VMware has issued patches and then recommended that customers uninstall them. Microsoft has also changed which microcode updates are installed for which processers, you can confirm your level of protection using these powershell-based test scripts.
Despite AMD’s initial claims that there were “near zero risks” to AMD processors they have begun to release microcode updates to mitigate these threats. These updates, in turn, are being distributed in the operating system and BIOS updates.
Our recommendations are different for end-user machines and servers. On end-user machines and devices, we recommend you immediately deploy all available patches, there is a small risk of increased reboots on some Intel-based systems, but we believe the benefits of these patches outweigh the risks.
Servers require more careful consideration in how you approach them. Unless your servers fall into high-risk levels (untrusted users are able to execute arbitrary programs they control ) or you handle particularly sensitive information it makes sense to delay deploying these patches until they are stabilized and recommended by your suppliers. Isolation of workloads of different security compartmentalization can help to mitigate the risk of these threats until the fixes required are sufficiently mature and stable.
Impact on our Managed Services
In our practice, we have evaluated the risks that impact Stack8’s Managed Services. We’ll share with you here our own evaluation to provide an example of how you can evaluate the risks and impacts in your environment.
The virtual servers used to manage and monitor customer environments as well as the host operating systems and physical servers that they reside on are affected by these vulnerabilities. Our systems are accessed by two different groups of users, the teams that manage our customer environments and the sysadmin team responsible for the administration of these servers. This means that the exploitation of these vulnerabilities would only give a user access to systems that they already have access too. While it’s important that we update our systems in order to maintain their security, there is no significant impact or risk to customers introduced by these issues.
While we were in the process of planning our patch deployment, VMware revised their recommendations and indicated that we should delay the deployment of the patches. At present we are waiting on stabilization before we deploy them; if we offered machines where customers had access to them and could deploy their own applications, then we would evaluate the risks differently and would be obliged to deploy the patches despite their potential impact.
If you need help securing your environment please do not hesitate to contact our Services Team.
Other Blogs You Might Enjoy
Ready to take your unified communications from headache to hassle-free?
No throwing darts at proposals or contracts. No battling through the back-end. No nonsense, no run-around.