VHOST-NET GUEST TO HOST ESCAPE - Kernel vulnerability - CVE-2019-14835
Updated
Was this information helpful?
Executive Summary
A buffer overflow vulnerability was found in the Linux kernel's networking virtualization functionality that could be abused during live migration(s) of virtual machine guests. A privileged guest user may pass descriptors with invalid length to the host when live migration is underway and escalate their privileges on the host.
Technical Details and Background
The issue has been assigned CVE-2019-14835 with a severity impact of Important.
This flaw can only be exploited during guest live migration(s). Patches and alternate mitigations are detailed below.
CVE-2019-14835 - kernel: vhost-net: guest to host kernel escape during migration
A buffer overflow vulnerability was found in the Linux kernel's networking virtualization functionality that could be abused during live migrations of virtual machine guests. A privileged guest user may pass descriptors with invalid length to the host, while live migration is underway, and escalate their privileges on the host. This is unlikely to affect single-host systems where guest live migration is not configured.
Acknowledgments
Red Hat would like to thank Peter Pi from Tencent Blade Team.
Additional References
https://www.openwall.com/lists/oss-security/2019/09/17/1
https://www.redhat.com/en/blog/introduction-virtio-networking-and-vhost-net
https://www.redhat.com/en/blog/deep-dive-virtio-networking-and-vhost-net
Impacted Products
Red Hat Product Security has rated this update as having a security impact of Important.
The following Red Hat product versions are impacted:
- Red Hat Enterprise Linux 6
- Red Hat Enterprise Linux 7
- Red Hat Enterprise Linux 8
- Red Hat Virtualization
- Red Hat OpenStack Platform (images shipping kernel)
- Container-Native Virtualization (CNV)
While Red Hat's Linux Containers are not directly impacted by virtualization flaws, their security relies upon the integrity of the host kernel’s environment. Red Hat recommends that you use the most recent versions of your container images. The Container Health Index, part of the Red Hat Container Catalog, can always be used to verify the security status of Red Hat containers. To protect the privacy of the containers in use, you will need to ensure that the Container host (such as Red Hat Enterprise Linux, Red Hat CoreOS or Atomic Host) has been updated against these attacks. Red Hat has released an updated Atomic Host for this use case.
Diagnose your vulnerability
Use the detection script to determine if your system is currently vulnerable to this flaw. To verify the legitimacy of the script, you can download the detached GPG signature as well.
Take Action
Red Hat customers running affected versions of the Red Hat products are strongly recommended to update them as soon as erratas are available. Customers are urged to apply the appropriate updates immediately.
NOTES
At this time there is no reliable method to detect if the exploit has successfully been run on a system due to the low-level method of exploitation.
Red Hat Product Security strongly recommends customers review the threat profile of their systems, especially multi-tenant workloads. Consider patching higher priority systems that require guest migration abilities.
A kpatch for customers running supported versions of Red Hat Enterprise Linux 7 or greater will be available. Please open a support case to gain access to the kpatch.
For more details about what a kpatch is: Is live kernel patching (kpatch) supported in RHEL 7 and beyond?
Updates for Affected Products
| Product | Package | Advisory/Update |
|---|---|---|
| Red Hat Enterprise Linux 8 (z-stream) | kernel | RHSA-2019:2827 |
| Red Hat Enterprise Linux 8 | kernel-rt | RHSA-2019:2828 |
| Red Hat Enterprise Linux 7 (z-stream) | kernel | RHSA-2019:2829 |
| Red Hat Enterprise Linux 7 | kernel-rt | RHSA-2019:2830 |
| Red Hat Enterprise Linux 7 | kpatch-patch | RHSA-2019:2854 |
| Red Hat Enterprise Linux 6 (z-stream) | kernel | RHSA-2019:2863 |
| Red Hat Virtualization 4.3 | redhat-virtualization-host | RHSA-2019:2889 |
| Red Hat Virtualization 4.2 EUS | redhat-virtualization-host | RHSA-2019:2924 |
Mitigation
Option #1 Disabling vhost-net
Vhost-net functionality can be disabled on a per-guest basis. See DISABLING VHOST-NET.
Alternatively, the kernel module named 'vhost_net' which contains the affected code can be blacklisted using the standard blacklisting techniques. See How do I blacklist a kernel module to prevent it from loading automatically? for instructions on how to complete the task.
Guests utilizing vhost-net functionality need to be rebooted for the changes to take effect.
Option #2 Disabling guest live migration
The issue is only exploitable from the guest when live migration is underway. Avoiding migration by either disabling automatic migration completely or not migrating the guests to another host manually, is an effective way to avoid exploitation.
CNV - Disable Live migration Support
Disable the live migration feature by removing the "LiveMigration" field from data: feature-gates: in the kubevirt-config configuration file, which is located in the kubevirt namespace
Procedure
Edit the kubevirt-config configuration file and remove the LiveMigration from the `feature-gates` line:
$ oc edit configmap kubevirt-config -n kubevirt
...
data:
feature-gates: "LiveMigration"
Remove the “LiveMigration” term in the line above.
The virt-api and virt-controller pods need to be restarted to apply the changes.
$ oc delete pod virt-api -n kube-system
$ oc delete pod virt-controller -n kube-system
Red Hat Virtualization - disabling automatic migration
Migrations can be disabled at either the cluster level or for individual guests. Typically, Red Hat Virtualization will automatically migrate guests to other hosts within a cluster according to load measurements, compatibility, and resilience and availability policy. Guests may also be migrated during maintenance as hosts within a cluster are put into maintenance mode.
Automatic migration policy can be controlled on a cluster level, or in individual host configuration.
- In a cluster, configuring Resilience Policy to “Do Not Migrate Virtual Machines” will prevent any virtual guests within that cluster from being migrated. See Administration Guide: Migration Policy Settings for more details.
- Individual guests can be prevented from participating in migration by pinning them to specific hosts or by setting Migration Options to “Do not allow migration”. See Management Guide: Preventing Automatic Migration of a Virtual Machine.
To ensure guests are not migrated when a host is put into maintenance mode, either make sure that the guests are configured with Do not allow migration, or shut down all the guests on that host before putting it into maintenance mode.
Customers are advised to take a risk-based approach to mitigating this issue. Systems that require high degrees of security and trust should be addressed first and isolated from untrusted systems until treatments can be applied to those systems to reduce the risk of exploit.
Performance Impact
Updating the kernel to a release that contains the fix will have no noticeable performance impact.
A performance impact is expected if using the mitigation of disabling vhost-net. The exact measures will be dependant on the networking load on the system.
Ansible Playbook
Additionally, a mitigation playbook is available which will prevent the vulnerable kernel module from being loaded. This playbook will reboot your systems to ensure the module is unloaded. To use it, specify the inventory names of the target systems in the HOSTS variable. For example:
ansible-playbook -e HOSTS=myhost1,myhost2 CVE-2019-14835_blacklist_mitigate.yml
A detached GPG signature is also available.
Comments