Information

Files

Advisory

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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

  Xapi: Metadata injection attack against backup/restore functionality

UPDATES IN VERSION 2
====================

Public release.

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 (VDI) 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.

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.

IMPACT
======

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.

CREDITS
=======

This issue was discovered by XenServer.

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
$

DEPLOYMENT DURING EMBARGO
=========================

Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.

But: Distribution of updated software is prohibited (except to other
members of the predisclosure list).

Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.


(Note: this during-embargo deployment notice is retained in
post-embargo publicly released Xen Project advisories, even though it
is then no longer applicable.  This is to enable the community to have
oversight of the Xen Project Security Team's decisionmaking.)

For more information about permissible uses of embargoed information,
consult the Xen Project community's agreed Security Policy:
  http://www.xenproject.org/security-policy.html
-----BEGIN PGP SIGNATURE-----

iQFABAEBCAAqFiEEI+MiLBRfRHX6gGCng/4UyVfoK9kFAmaWYLkMHHBncEB4ZW4u
b3JnAAoJEIP+FMlX6CvZTwkIALcgQmF/UVzUfs54omUKi+E4woQmfEOPO1GNki5x
abjnmv7Nos7AJem6ytX2eLLcPvl7iEtFf8p+pYdXwjjyT+Gtg2+8E/k8m7b4Qx3u
ZoW0ID3LBNb0++Tc+DKJKuEOMg2/OINbcFqAQUWutzbz38QCMJ30JyAkZKU/UYmL
Hs/xb65PpI1khaZD/1ipjxCDP/XJIzV2l1vD23omb1TXiWhsdHtT9YKiypThECnA
/uBUyKHOC9+Tx1eYrG0H8am8t2MKoOQL0Lu2xWFJskrg2LHYkxk3he0OTKWcsVTz
OYs1ReZt1k9KSwpqsIq5uJj/HARUCm+fPmL126IB4q5tMQ4=
=9K9F
-----END PGP SIGNATURE-----