Xen Security Advisory CVE-2024-31144 / XSA-459

  Xapi: Metadata injection attack against backup/restore functionality

              *** EMBARGOED UNTIL 2024-07-16 12:00 UTC ***

ISSUE DESCRIPTION
=================

For a brief summary of Xapi terminology, see:

  https://xapi-project.github.io/xen-api/overview.html#object-model-overview

Xapi contains functionality to backup and restore metadata about Virtual
Machines and Storage Repositories (SRs).

The metadata itself is stored in a Virtual Disk Image inside an SR.
This is used for two purposes; a general backup of metadata (e.g. to
recover from a host failure if the filer is still good), and Portable
SRs (e.g. using an external hard drive to move VMs to another host).

Metadata is only restored as an explicit administrator action, but
occurs in cases where the host has no information about the SR, and must
locate the metadata VDI in order to retrieve the metadata.

The metadata VDI is located by searching (in UUID alphanumeric order)
each VDI, mounting it, and seeing if there is a suitable metadata file
present.  The first matching VDI is deemed to be the metadata VDI, and
is restored from.

In the general case, the content of VDIs are controlled by the VM owner,
and should not be trusted by the host administrator.

IMPACT
======

A malicious guest can manipulate its disk to appear to be a metadata
backup.

A guest cannot choose the UUIDs of its VDIs, but a guest with one disk
has a 50% chance of sorting ahead of the legitimate metadata backup.  A
guest with two disks has a 75% chance, etc.

If a fraudulent metadata backup has been written into an SR which also
contains a legitimate metadata backup, and an administrator explicitly
chooses to restore from backup, the fraudulent metadata might be
consumed instead of the legitimate metadata.

Control over meta data includes: which VMs are created, disk assignment,
vCPU/RAM requirements, GPU allocation, etc.

VULNERABLE SYSTEMS
==================

Systems running Xapi v1.249.x are affected.

Systems running Xapi v24.x are potentially affected.  However it is
believed that the only supported products using this version of Xapi
have not shipped the metadata backup/restore functionality.

To leverage the vulnerability, an attacker would likely need insider
information to construct a plausible-looking metadata backup, and would
have to persuade a real administrator to perform a data-recovery action.

MITIGATION
==========

Not using the metadata restore functionality avoids the vulnerability.

RESOLUTION
==========

The attached patches resolve the issue for Xapi v1.249.x releases.

xsa459-xen-api.patch (based on v1.249.37) causes all new metadata VDIs
to be created with a deterministic UUID, and restore functionality to use
that UUID only; not to search all disks to find the metadata.

After installing the updated Xapi, a new metadata backup should be
taken, to create a VDI with the new deterministic UUID.

The ability to restore from an old backup VDI is retained, but the
administrator is required to specify the exact VDI to use, so as to
avoid searching the SR.

Because xsa459-xen-api.patch alters the behaviour of the
xe-{backup,restore}-metadata scripts, a companion patch
xsa459-xsconsole.patch (based on v10.1.13.1) is needed to keep the
pre-existing menu options working, and to ask for user conformation if
needing to restore from a prior backup.

Note: some work was carried out in public on this issue before the
security implications were understood.  These changes are present in
xen-api.git and tagged as v1.249.37, which is used as the base for this
patch.

$ sha256sum xsa459*
89dba36a1889a41fbf585a25432079d10991d9e9f3c2d9f93f285c11e17e02c3  xsa459-xen-api.patch
0fc4dabd3a84055644fe415f55d8a1148ad2c17aaa2f8b52889cb11800c612d2  xsa459-xsconsole.patch
$