From 8f35fd21cca2bd703bb47e3066d96ec699accbeb Mon Sep 17 00:00:00 2001 From: "Daniel P. Berrange" Date: Mon, 14 Oct 2013 18:05:19 +0100 Subject: [PATCH] Add some notes about secure usage of libvirt Start a page describing some of the things that applications using libvirt need to bear in mind to ensure security of their systems. Signed-off-by: Daniel P. Berrange --- docs/secureusage.html.in | 171 +++++++++++++++++++++++++++++++++++++++ docs/sitemap.html.in | 4 + 2 files changed, 175 insertions(+) create mode 100644 docs/secureusage.html.in diff --git a/docs/secureusage.html.in b/docs/secureusage.html.in new file mode 100644 index 0000000000..af47a0f53f --- /dev/null +++ b/docs/secureusage.html.in @@ -0,0 +1,171 @@ + + + + + +

Secure Usage of Libvirt

+ + + +

+ This page details information that application developers and + administrators of libvirt should be aware of when working with + libvirt, that may have a bearing on security of the system. +

+ + +

Disk image handling

+ +

Disk image format probing

+ +

+ Historically there have been multiple flaws in QEMU and most + projects using QEMU, related to handling of disk formats. + The problems occur when a guest is given a virtual disk backed + by raw disk format on the host. If the management application + on the host tries to auto-detect / probe the disk format, it + is vulnerable to a malicious guest which can write a qcow2 + file header into its raw disk. If the management application + subsequently probes the disk, it will see it as a 'qcow2' disk + instead of a 'raw' disk. Since 'qcow2' disks can have a copy + on write backing file, such flaw can be leveraged to read + arbitrary files on the host. The same type of flaw may occur + if the management application allows users to upload pre-created + raw images. +

+ +

+ Recommendation: never attempt to automatically + detect the format of a disk image based on file contents which + are accessible to / originate from an untrusted source. +

+ +

Disk image backing files

+ +

+ If a management application allows users to upload pre-created + disk images in non-raw formats, it can be tricked into giving + the user access to arbitrary host files via the copy-on-write + backing file feature. This is because the qcow2 disk format + header contains a filename field which can point to any location. + It can also point to network protocols such as NBD, HTTP, GlusterFS, + RBD and more. This could allow for compromise of almost arbitrary + data accessible on the LAN/WAN. +

+ +

+ Recommendation: always validate that a disk + image originating from an untrusted source has no backing + file set. If a backing file is seen, reject the image. +

+ +

Disk image size validation

+ +

+ If an application allows users to upload pre-created disk + images in non-raw formats, it is essential to validate the + logical disk image size, rather than the physical disk + image size. Non-raw disk images have a grow-on-demand + capability, so a user can provide a qcow2 image that may + be only 1 MB in size, but is configured to grow to many + TB in size. +

+ +

+ Recommendation: if receiving a non-raw disk + image from an untrusted source, validate the logical image + size stored in the disk image metadata against some finite + limit. +

+ +

Disk image data access

+ +

+ If an untrusted disk image is ever mounted on the host OS by + a management application or administrator, this opens an + avenue of attack with which to potentially compromise the + host kernel. Filesystem drivers in OS kernels are often very + complex code and thus may have bugs lurking in them. With + Linux, there are a large number of filesystem drivers, many + of which attract little security analysis attention. Linux + will helpfully probe filesystem formats if not told to use an + explicit format, allowing an attacker the ability to target + specific weak filesystem drivers. Even commonly used and + widely audited filesystems such as ext4 have had + bugs lurking in them + undetected for years at a time. +

+ +

+ Recommendation: if there is a need to access + the content of a disk image, use a single-use throwaway virtual + machine to access the data. Never mount disk images on the host + OS. Ideally make use of the libguestfs + tools and APIs for accessing disks +

+ +

Guest migration network

+ +

+ Most hypervisors with support for guest migration between hosts + make use of one (or more) network connections. Typically the source + host will connect to some port on the target host to initiate the + migration. There may be separate connections for co-ordinating the + migration, transferring memory state and transferring storage. + If the network over which migration takes place is accessible the + guest, or client applications, there is potential for data leakage + via packet snooping/capture. It is also possible for a malicious + guest or client to make attempts to connect to the target host + to trigger bogus migration operations, or at least inflict a denial + of service attack. +

+ +

+ Recommendations: there are several things to consider + when performing migration +

+ + + +

Storage encryption

+ +

+ Virtual disk images will typically contain confidential data + belonging to the owner of the virtual machine. It is desirable + to protect this against data center administrators as much as + possible. For example, a rogue storage administrator may attempt + to access disk contents directly from a storage host, or a network + administrator/attack may attempt to snoop on data packets relating + to storage access. Use of disk encryption on the virtualization + host can ensure that only the virtualization host administrator + can see the plain text contents of disk images. +

+ +

+ Recommendation: make use of storage encryption + to protect non-local storage from attack by rogue network / + storage administrators or external attackers. This is particularly + important if the storage protocol itself does not offer any kind + of encryption capabilities. +

+ + + diff --git a/docs/sitemap.html.in b/docs/sitemap.html.in index a8d2177983..d821a9e818 100644 --- a/docs/sitemap.html.in +++ b/docs/sitemap.html.in @@ -136,6 +136,10 @@ Node Devices Enumerating host node devices +
  • + Secure usage + Secure usage of the libvirt APIs +