diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 000000000..13a9c438e --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,68 @@ +# Cloud Hypervisor Security Policy + +## What Is A Vulnerability? + +Cloud Hypervisor's threat model is in [docs/threat-model.md](docs/threat-model.md). +A vulnerability is defined as an entity defined in the threat model as +untrusted being able to cause Cloud Hypervisor to do something that the +threat model states it should not be able to cause. + +Any known or potential memory corruption is assumed exploitable until +and unless proven otherwise. Attackers have shown repeatedly that memory +corruption can usually be turned into arbitrary code execution. While +doing so may be very difficult, LLMs have made this much easier. + +Mishandling of a memory allocation failure (either user-mode or +kernel-mode) is still in scope. While this will typically result in +Cloud Hypervisor crashing, Cloud Hypervisor must not corrupt its own +memory or otherwise behave insecurely. + +## How To Report A Vulnerability? + +Vulnerabilities should be reported using the GitHub Security Advisory +process. Do not file an issue, as that immediately gives malicious +actors knowledge of the vulnerability. A proof of concept is strongly +preferred but not strictly required. A patch is also greatly +appreciated but is also not a requirement. + +Cloud Hypervisor does not currently have any bug bounty program. + +The use of automated tooling to find vulnerabilities is encouraged. +This includes large language models and other forms of AI. The tool used +should be noted in the report. The human making the report is +responsible for its contents and for filtering out false positives. + +It is not expected that every single report will be valid, but reporters +must make a good-faith effort to avoid false positives. Striving to achieve a +zero false-positive rate will reduce the number of correct reports and is not +worthwhile. + +## When A Vulnerability Is Reported + +The Cloud Hypervisor maintainers will triage any reported +vulnerabilities. Once patches are ready, an embargo period of up to 14 +days starts. There will be a public announcement that a vulnerability +is under embargo, along with its GHSA number. + +The following organizations will receive full access to embargoed +information. They are only permitted to use this information for +preparing and deploying patches. Information must be limited to those +who need to know. This includes access to both patched source code and +patched binaries. + +- Microsoft +- Crusoe +- Cyberus Technology +- Meta +- Google +- UbiCloud + +This list may be extended by filing a PR. It will only include: + +- Organizations that distribute Cloud Hypervisor to a significant number + of users. + +- Organizations that use Cloud Hypervisor to provide a managed service + to a significant number of users. + +The list is documented here for the purposes of transparency. diff --git a/docs/threat-model.md b/docs/threat-model.md new file mode 100644 index 000000000..d95b48411 --- /dev/null +++ b/docs/threat-model.md @@ -0,0 +1,226 @@ +# Cloud Hypervisor Threat Model + +The interfaces Cloud Hypervisor interacts with can be divided into four groups: + +1. Hardware and software responsible for the execution of Cloud Hypervisor. +2. Management interfaces used to configure and control Cloud Hypervisor. +3. Guest-facing interfaces used by guest virtual machines. +4. Data-plane interfaces used for guest I/O. + +## Cloud Hypervisor's Execution Environment + +Like any other program, Cloud Hypervisor must trust the hardware, +firmware, and software responsible for executing it. This includes, but +is not limited to: + +- The CPU, including (if present) its microcode and privileged firmware. +- The Linux kernel. +- Any hypervisor or emulation environment the kernel is running on. +- Any hypervisor or emulator Linux is running on. This includes both + using KVM under nested virtualization and using MSHV. + +Cloud Hypervisor assumes that these components have been configured to +provide isolation. This includes, but is not limited to: + +- Using an up-to-date kernel, microcode, and firmware. +- If MSHV is in use, using an up-to-date version of MSHV. +- Enabling mitigations for all known hardware vulnerabilities. +- Disabling SMT (simultaneous multithreading) if necessary. +- Enabling Data Operand Independent Timing Mode (DOITM) on Intel systems + that have it to avoid timing side-channel vulnerabilities in + cryptographic code. + +Cloud Hypervisor does protect the host kernel from vulnerabilities in +kernel code it does not use. For instance, Cloud Hypervisor does not +use user namespaces, AF_ALG, or splice(), so vulnerabilities that +require any of these cannot be exploited by a Cloud Hypervisor guest. + +## Management Interfaces + +Cloud Hypervisor can be configured and controlled via three ways: + +- The command-line passed to the Cloud Hypervisor process. +- An HTTP API. +- A D-Bus API. + +These interfaces are considered trusted. For instance, Cloud Hypervisor +does not prevent an API client from telling Cloud Hypervisor to access +/proc/self/mem and thus overwrite its own memory. Nevertheless, it is +safe and useful for management stacks to perform some management actions +on behalf of untrusted parties. For instance, a cloud service may allow +users to upload arbitrary files and attach them to their VMs as block +devices. + +## Guest Virtual Machine + +Cloud Hypervisor considers the guest VM to be untrusted. This means that +a guest VM is only allowed to perform I/O using the interfaces Cloud +Hypervisor has been told to provide to it. + +Cloud Hypervisor is not hardened against denial of service attacks from +the guest kernel it is running. The guest may cause Cloud Hypervisor to +crash in a non-exploitable way, such as a Rust panic. Cloud Hypervisor +assumes that a guest doing this only hurts itself. + +Cloud Hypervisor only provides the guest VM with a limited number of +vCPUs and a limited amount of memory. However, a guest might be able to +cause Cloud Hypervisor itself to consume excessive CPU or memory. +Applications that need to impose limits on guest CPU or memory usage +should rely on control groups, which provide kernel-enforced resource +limits. + +Cloud Hypervisor assumes that guest VMs may have internal security +boundaries. For instance, a guest OS may run untrusted userspace +programs or nested VMs. Cloud Hypervisor cannot be used as a confused +deputy to violate these boundaries, unless the guest allows userspace to +drive a Cloud Hypervisor-provided device. This includes both in-guest +privilege escalation and in-guest denial of service. + +It is not safe to use a userspace driver for a device provided by Cloud +Hypervisor *except* on Arm64 with a virtio IOMMU. While a virtio IOMMU +is provided on x86_64, it does not provide interrupt remapping and so +does not provide strong isolation. Even then, the userspace driver can +still cause Cloud Hypervisor (and thus the guest) to crash due to bugs +in the PCI emulation code. These bugs should still be fixed, but they +are not considered vulnerabilities at this time. + +## Confidential Computing + +Even when running a confidential guest VM, Cloud Hypervisor still +assumes the guest VM trusts Cloud Hypervisor. Cloud Hypervisor may +attempt to access guest memory that is private to the confidential VM. +It is the responsibility of the hardware, firmware, and guest to ensure +that such accesses fail. If accessing host-inaccessible guest memory +can cause a host-wide denial of service, it is the responsibility of +the host kernel to prevent such accesses. + +## Vhost-User Devices + +Cloud Hypervisor gives vhost-user devices complete control over the +guest. Cloud Hypervisor does not allow vhost-user devices to take +control over the Cloud Hypervisor process itself. + +If a virtio IOMMU is in use, it is the responsibility of the vhost-user +device to use it for address translation. + +## I/O Devices + +The I/O devices exposed by Cloud Hypervisor allow guests to send and +receive arbitrary data. Cloud Hypervisor threats this data as opaque. + +Cloud Hypervisor does not allow a guest to write to read-only storage +devices. Cloud Hypervisor also does not allow MAC address spoofing, if +a MAC address is provided. + +With the above exceptions, Cloud Hypervisor does not filter data sent +and received by the guest in any way. If such filtering is necessary, it +must be done outside of Cloud Hypervisor. For instance, network traffic +can be filtered by a firewall. + +## Files Provided to Cloud Hypervisor + +### File names + +Cloud Hypervisor does not protect against symlink attacks when opening +files. Files that Cloud Hypervisor is told to open must be in paths +that are protected from symlink attacks. This can be accomplished by +mounting filesystems with `nosymfollow`. + +Cloud Hypervisor does not protect against being told to open a file in +`/proc`. Accesses to such a files could corrupt Cloud Hypervisor's own +memory. + +In short, if an untrusted entity is allowed to choose a filename, a +trusted component must ensure that path traversal attacks are blocked. + +The safest way to provide a file to Cloud Hypervisor is via a file +descriptor. + +### Disk Images + +With one exception, Cloud Hypervisor assumes that disk images provided +to it are untrusted. The exception is that qcow2 images are assumed +trusted if the `backing_files` option is enabled. It is disabled by +default. If a backing file must be used with an untrusted image, the +management stack must validate that the backing file is the expected +value and resides in sector 0. + +Cloud Hypervisor does not protect against decompression bombs. +This means that malicious compressed data in a qcow2 image can cause +Cloud Hypervisor to use very large amounts of CPU and/or memory. + +If a non-raw disk image is not corrupt, Cloud Hypervisor does not allow +a guest to corrupt it. If it is corrupt and writable, it may be further +corrupted in an arbitrary way, except that the header of a qcow2 image +will not be altered. + +Provided that symlink attacks are avoided and backing files are not +used, it is safe to provide a file backed by an untrusted FUSE +filesystem, or by a trusted FUSE file backed by untrusted network +storage. This means that Cloud Hypervisor must be secure even if an +attacker can cause I/O to complete at times of their choosing. Cloud +Hypervisor must also be secure against time-of-check to time-of-use +attacks. + +### Virtual Firmware + +Cloud Hypervisor does not itself trust the firmware image, but assumes +that the guest does trust it. + +### Guest Kernel and Initramfs + +Cloud Hypervisor does not itself trust the guest kernel and initramfs. +Unless the guest uses secure boot, the guest must itself trust them. + +## PCI and vDPA devices + +By default, Cloud Hypervisor provides PCI and vDPA devices assigned to a +guest with access to all guest memory. Therefore, these devices can take +over the guest. Even if a virtual IOMMU is enabled, there is no +interrupt remapping on x86\_64, so a device can probably use malicious +MSIs to take over a guest. On Arm, the GIC performs interrupt remapping, +so a guest could theoretically defend itself from a malicious device. +However, it is extremely unlikely that a real-world guest actually does. + +However, it is possible for a guest to influence the behavior of PCI and +vDPA devices attached to it. Therefore, Cloud Hypervisor treats these +devices as untrusted. This is done by only allowing them to access +memory that is mapped into the guest. They are not allowed to access +Cloud Hypervisor's own memory. + +Cloud Hypervisor *cannot* protect against hardware infection. Attackers +may attempt to install malicious firmware on a device, tamper with an +option ROM, or otherwise attempt to retain control of the device after +the host reboots. If the attacker succeeds, they can compromise the host +through any of a number of methods. These include, but are not limited +to, DMA attacks and impersonating trusted devices like a keyboard or OS +boot disk. + +Systems where assigned devices have no mutable state that persists +across host CPU resets are not vulnerable to such attacks. If the device +has a secure boot process and is power cycled whenever the host resets, +the system may also not be vulnerable. This depends heavily on both the +host and device firmware and hardware design and no generic statement +can be given. SR-IOV virtual functions (including vDPA) are the safest +options, as they are intended to be assigned to guests. A detailed +explanation is beyond the scope of this policy. + +## Sandboxing + +Cloud Hypervisor can sandbox itself via Landlock and seccomp. Once +sandboxed, Cloud Hypervisor is not able to access any resources blocked +by the sandbox. This is true even if an attacker can execute arbitrary +code in the context of the Cloud Hypervisor process. + +The sandbox only prevents access to resources subject to Landlock access +controls. For instance, it does not prevent access to AF\_UNIX sockets. +This can be blocked via namespaces or by other kernel-enforced access +controls. Additionally, the restricted resources are limited by the +version of the Landlock API Cloud Hypervisor uses. + +Until support for blocking AF\_UNIX sockets is implemented in Landlock +and used by Cloud Hypervisor, sandbox escapes will not be considered +security vulnerabilities. Once Cloud Hypervisor enables and uses +AF\_UNIX socket restrictions, sandbox escapes will be considered +security vulnerabilities. This only applies to sandbox escapes that do +not exploit vulnerabilities in the host kernel.