Turbonomic Software and the Meltdown and Spectre Vulnerabilities

Document created by jerryl on Jan 9, 2018Last modified by jerryl on Jan 9, 2018
Version 3Show Document
  • View in full screen mode

Turbonomic Software and the Meltdown

and Spectre Vulnerabilities

 

The last few days have seen an explosion of articles about a series of new attacks, mainly on Intel CPU's running Linux or Windows.  This article explains, in broad terms, what these attacks are; why Turbonomic software VM's are not significantly affected by them; and what users may wish to do in mitigating any remaining vulnerabilities.

 

What Do Meltdown and Spectre Do?

Both of these bugs provide ways for a hostile program to examine a "security zone" to which it does not have access.  Here's a simple analogy:  When you go to a hotel, you share the building with many other hotel customers.  But you expect your room to be private to you.  You don't want other customers to be able to get into your room.  Each room - or perhaps a group of rooms in a suite - is a "security zone".  There's actually another "master" security zone which is somewhat more abstract:  Hotel management.  Hotel management has access to all rooms, though it's presumed to act in its guest's interests.  It also retains guest's private information, like credit card details.  No guest should be allowed access to management's information.

 

In a traditional time-shared computer system, your process is a "security zone" akin to your room at the hotel, and the operating system is the "master" security zone like hotel management, entrusted to manage your process and some of its secret data (e.g., login passwords).  At a higher level, in a virtualized environment, each VM is a "security zone", and the hypervisor is the "master security zone".  Even on your laptop, where only you log in, Javascript downloaded from some shopping Web site shouldn't be allowed access to your private data, even though you are running it - so your browser keeps it in its own security zone.

 

While the technical details of Meltdown and Spectre are complex, they allow "peeking through the keyholes", extracting data from other processes running under the same operating system, other VM's on the same host, or even other processes on a laptop from a Javascript.  In practice, these attacks target the "master" security zone - the operating system or hypervisor.

 

Patches are being developed for operating systems and hypervisors that block these attacks.  Unfortunately, these patches may have significant overhead - numbers reported indicate a slowdown of anywhere from almost nothing to 30%.  There's little information available so far to judge the performance impact on any particular kind of application, though enterprise-like applications seem to be harder hit.

 

The Case of Turbonomic Software

Turbonomic software runs in a dedicated VM.  Everything running in that VM is there for the express purpose of supporting the Turbonomic software.  (Unlike a hotel, this VM is like a family's home.)  While various components are isolated from each other - thus are technically in separate security zones - they are not hostile to each other:  The Apache and Tomcat services run under different accounts, but we don't expect one of them to try to attack the other!  User-written code in a Turbonomic VM is limited - e.g., action scripts - and must be trusted, as it's tightly integrated with the Turbonomic software itself.  The security design of the Turbonomic VM considers all accounts to be root-equivalent, as a non-root-equivalent account can perform no useful functions on the VM.  A root-equivalent user doesn't need attacks like Meltdown or Spectre - he already has full access to the VM.

 

Hence, the threat of a Meltdown or Spectre attack inside of a Turbonomic VM is minimal.

 

Note that attacks against the Turbonomic VM by other VM's on the same host are an entirely different matter.  These are plausible and if successful might have serious security implications.  However, mitigating such attacks cannot be done from within the VM or its operating system:  It must be done by patching the hypervisor controlling the host.  VMware has announced upcoming patches for ESX; Microsoft is planning a reboot of all its Azure hosts exactly to put HyperV patches in place.  Other hypervisor patches have no doubt been released or soon will be.

 

But I Want To Protect My Turbonomic VM Anyway

Doing so may well be prudent.  It may be required by your site's security policy.

 

Turbonomic does not redistribute Linux OS patches.  Turbonomic updates modify our own software and third-party libraries we integrate with.

 

Turbonomic periodically creates a new virtual machine image, it applies all relevant OS patches that are available.  Applying OS patches to an existing Turbonomic VM is the responsibility of the Turbonomic customer.

 

  • If your Turbonomic VM is running the openSUSE operating system (Turbonomic software 5.9 or earlier only), you must perform a migration to a new VM running the CentOS operating system.  All support for openSUSE was ended by the vendor over a year ago; no patches for new vulnerabilities are being issued.  If this applies to you, or if you are uncertain, please contact Turbonomic Customer Support for assistance.
  • If you are running CentOS, you can apply all available security patches from the command line using the "yum --security update".  Use of this command requires that the Turbonomic VM have access to the Internet so that it can download the updates.  If that's not the case for your instance, please contact Customer Support for assistance.  Turbonomic will support any Turbonomic VM updated using this command.  Do not omit the --security option!  Doing so may apply patches inconsistent with the Turbonomic software.
  • If you are running a custom Red Hat installation, please contact your local security organization for information on how to proceed.

 

Some Technical Details

The Meltdown and Spectre vulnerabilities are described in CVE-2017-5753, CVE-2017-5715, and CVE-2017-5754.

 

CentOS updates have been published; the details can be found at https://lists.centos.org/pipermail/centos-announce/2018-January/022696.html.  Note that these patches may be updated over time.

 

Turbonomic is currently unable to estimate the impact of applying these patches, or the relevant hypervisor patches, to performance of the Turbonomic software.  If this impact proves to be high, existing highly loaded Turbonomic software instances may require additional CPU resources to continue to effectively managing your infrastructure.

 

Please contact Customer Support if you feel that your Turbonomic software instance has been adversely affected by applying the patches.

2 people found this helpful

Attachments

    Outcomes