CVE-2024-31144 - Exploiting Xapi Metadata Restore - How Untrusted Data Can Compromise Your Host

CVE-2024-31144 is a security issue affecting the XAPI Project, a key component in managing XenServer and XCP-ng virtualization infrastructure. This vulnerability arises from the way Xapi restores metadata from disk images that can be fully controlled by virtual machines (VMs). In this post, we’ll explain what this means, show code samples for understanding the root cause, go over how the exploit works, and provide links to official documentation for further reading.

What is Xapi and its Metadata Backup?

Xapi is the management API behind allowing you to control virtual machines, storage, and networking from a central controller or cloud. For background on its object model and terminology, see the official Xapi object model overview.

Xapi has a function to backup and restore important metadata about Virtual Machines (VMs) and Storage Repositories (SRs). This metadata is critical for moving VMs between hosts or for disaster recovery. These backups are stored in special Virtual Disk Images (VDIs) attached to storage repositories.

The Vulnerability: Trusting Untrusted Disk Images

### How Xapi Finds VM/SR Metadata

When restoring from a backup, Xapi has no way to initially verify which VDI actually contains legitimate backup data. To find the right VDI, Xapi will:

The Flaw

In normal operation, the contents of these VDIs are actually under full control of the VM owner (the guest). The host administrator cannot trust what’s inside these disks, as the guest could have put anything there.

A malicious guest can create a disk that mimics the expected metadata file structure. If this disk happens to be ahead in the UUID sort order, the host will restore metadata from this untrusted VDI—even if more legitimate backup VDIs exist.

n VDIs: Probability approaches 100% with more disks.

This means the more fake disks a guest attaches, the higher the odds they can control which metadata gets restored.

Attaches this VDI (or several) to the Storage Repository (SR).

3. When Xapi attempts to restore backup metadata after a host failure or when portable storage is attached, it sorts all VDIs by UUID and checks each in turn.
4. If the malicious VDI comes before the real backup in sort order, Xapi restores metadata from attacker-controlled content.

Below is a simplified Python code snippet showing how Xapi attempts to locate the metadata VDI

# Simplified logic that mimics Xapi's metadata restore search
import os

def is_metadata_file(vdi_path):
    # Check for file signature (dummy logic for illustration)
    meta_file = os.path.join(vdi_path, 'metadata_backup')
    return os.path.exists(meta_file)

def find_metadata_vdi(vdi_mount_points):
    # vdi_mount_points: dict of {UUID: mount_path}
    for uuid in sorted(vdi_mount_points.keys()):
        mount_path = vdi_mount_points[uuid]
        if is_metadata_file(mount_path):
            print(f"Found metadata VDI: {uuid}")
            return uuid
    return None

# Example usage
vdi_mount_points = {
    "1111-aaaa": "/mnt/vdi1",   # Malicious disk with metadata_backup file
    "2222-bbbb": "/mnt/vdi2",   # Legitimate backup disk
}
metadata_vdi = find_metadata_vdi(vdi_mount_points)
print(f"Metadata restored from VDI UUID: {metadata_vdi}")

This code would restore from the disk with UUID 1111-aaaa if it comes first in the order—regardless of whether it’s an honest backup or an attacker’s fake.

Trick the host into restoring malicious configuration or metadata.

- Overwrite or inject unauthorized VM/storage records.

Potentially compromise the host or other VMs due to tampered management state.

The biggest risk is after a host failure or when using portable media to move repositories between hosts, as the “search and restore” process will be triggered.

Never restore metadata from disks unless their origin is authenticated and verified.

- Xapi should offer options to verify the creator or add metadata signing/verification.
- Carefully review SR contents before performing a restore, and isolate backup VDIs from guest-writable disks.

References & Further Reading

- Xapi Project – Object Model and Overview
- CVE-2024-31144 at MITRE *(if/once it’s public)*
- Xapi-Project GitHub repository

Conclusion

CVE-2024-31144 shows how trusting guest-controlled data for core infrastructure actions is dangerous. The Xapi restore process gives attackers a surprising amount of control simply due to how it looks for rescue metadata, with probabilities that can be heavily tipped in the attacker’s favor. Awareness and careful design are needed to ensure that only trusted sources are used for backup and recovery operations.

If you use Xen or Xapi, review your backup strategies and stay tuned for patches that address this risky behavior!


*(If you found this useful, share with your virtualization admin friends and help keep our platforms secure!)*

Timeline

Published on: 02/14/2025 21:15:15 UTC
Last modified on: 02/18/2025 15:15:16 UTC