Foreshadow Attack Issues

This page includes the current information on released updated packages and templates, as well as recommendations related to dealing with the Foreshadow vulnerabilities. The page will be updated as soon as we have new information for you.

Foreshadow is a speculative execution attack on Intel processors which allows an attacker to steal sensitive information stored inside personal computers or third party clouds. For more details, refer to Foreshadow Attack

OnApp compute resources are affected by the following vulnerabilities:

CVE-2018-3615 - L1 Terminal Fault: SGX

  • Systems with microprocessors utilizing speculative execution and Intel® software guard extensions (Intel® SGX) may allow unauthorized disclosure of information residing in the L1 data cache from an enclave to an attacker with local user access via a side-channel analysis.
  • 7.3 High CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N

CVE-2018-3620 - L1 Terminal Fault: OS/SMM

  • Systems with microprocessors utilizing speculative execution and address translations may allow unauthorized disclosure of information residing in the L1 data cache to an attacker with local user access via a terminal page fault and a side-channel analysis.
  • 7.1 High CVSS:3.0/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N

CVE-2018-3646 - L1 Terminal Fault: VMM

  • Systems with microprocessors utilizing speculative execution and address translations may allow unauthorized disclosure of information residing in the L1 data cache to an attacker with local user access with guest OS privilege via a terminal page fault and a side-channel analysis.
  • 7.1 High CVSS:3.0/AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N

CVE-2018-3639 - Speculative Store Bypass (SSB) – also known as Variant 4

  • Systems with microprocessors utilizing speculative execution and speculative execution of memory reads before the addresses of all prior memory writes are known may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis.
  • 4.3 Medium CVSS:3.0/AV:L/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N

General Update on KVM CloudBoot for OnApp 5.0

Update [Sept 17, 2018 15:51 PT]

CloudBoot compute resources are recommended to update to the recent version:

  • CloudBoot CentOS 6 KVM Compute Resource
    Kernel 2.6.32-754.3.5.el6.x86_64

To apply the update:

1. Upgrade CloudBoot Packages to the onapp-store-install-5.0.0-42.noarch.rpm version

2. When the CloudBoot packages upgrade is complete, stop all virtual servers which reside on the CloudBoot compute resources.

3. Reboot all CloudBoot compute resources.

General Update on KVM CloudBoot for OnApp 5.5

Update [Sept 03, 2018 15:30 PT]

CloudBoot compute resources are recommended to update to the recent version:

  • CloudBoot KVM Compute Resource
    • CentOS 6 KVM
      Kernel 2.6.32-754.3.5.el6.x86_64
    • CentOS 7 KVM
      Kernel 3.10.0-862.11.6.el7.x86_64  

To apply the update:

1. Upgrade CloudBoot Packages to versions onapp-ramdisk-centos6-kvm-5.5.0-54.noarch.rpm and onapp-ramdisk-centos7-kvm-5.5.0-54.noarch.rpm

2. When the CloudBoot packages upgrade is complete, stop all virtual servers which reside on the CloudBoot compute resources.

3. Reboot all CloudBoot compute resources.

General Update on KVM Static for all OnApp Versions

Update [Aug 14, 2018 8:15 am, PT]

CentOS KVM static compute resources are recommended to update to the recent version:

  • Static KVM Compute Resource (CentOS 6/7)
    • CentOS 6 KVM 
      Kernel 2.6.32-754.3.5.el6.x86_64
    • CentOS 7 KVM
      Kernel 3.10.0-862.11.6.el7.x86_64

To update the kernel:

1. Run the following command:

# yum update kernel

2. Reboot the compute resource.

Migrate and Reboot

Live Upgrade is only applicable if your cloud is running latest 5.3 or 5.4 CloudBoot RPM.

Use this procedure if you prefer migrating all virtual servers to another compute resource and conducting overall upgrade of your CloudBoot and Integrated Storage. Virtual servers that do not support hot migrate will have to be stopped.

Once you have upgraded the CloudBoot packages, you have to reboot your CloudBoot compute resources to update them.

To do so:

  1. Run the following command from the Control Panel server terminal to display the list of compute resources with their IP addresses. Make a note of the list of IPs:

    CP_host#> liveUpdate listHVs

    If the command liveUpdate is not available, then it may be located in the sbin directory instead (cd /usr/local/sbin).
  2. Run the following command for every compute resource:

    CP_host#> liveUpdate updateToolstack <HV IP Addr>

  3. Migrate all the virtual servers from the CloudBoot compute resource to another compute resource. Follow the instructions described in the Migrate Virtual Server section of the Admin guide to migrate virtual servers.

  4. After that, go to your Control Panel Settings menu.

  5. Click the Compute Resources icon.

  6. Click the label of the CloudBoot compute resource you have migrated all VSs from.

  7. On the compute resource details screen, click the Actions button, then click Reboot Compute resource.

    Rebooting a compute resource assigned to a data store with a single replica (single-replica compute resource) or degraded virtual disks may result in data loss.


  8. A new screen will open asking for confirmation (via two check boxes) before reboot:

    • Stop all virtual servers that cannot be migrated to another compute resource? Check this box if you want VSs that cannot be migrated to be powered off. When a compute resource is scheduled for a reboot, OnApp will first attempt to hot migrate all VSs it hosts. If hot migration is not possible for a VS, OnApp will attempt to cold migrate that VS. With this box checked, if cold migration fails, the VS will be stopped so the reboot may proceed. If you don't check this box, OnApp will attempt to hot and then cold migrate all VSs hosted by the compute resource being rebooted – but will stop the migration process if any VS cannot be migrated.
    • Are you sure you want to reboot this compute resource? A simple confirmation to confirm that you want the compute resource to reboot.

      Before the reboot, please ensure that all vdisks are fully synced and redundant. If some of them are not fully synced, the virtual server, that is owner of a degraded (or non-redundant) vdisk, can loose access to the vdisk. It can be manifested as IO errors during writes or reads to/from the vdisk inside the virtual server.
  9. When you're certain you want to proceed with the reboot, click the Reboot button.

  10. Repeat these steps for all CloudBoot compute resources in your cloud.