*CVE-2022-42323* highlights a weakness in the Xen Hypervisor’s Xenstore service, uncovering how two collaborating virtual machines (VMs), or “guests,” can fill the hypervisor’s core configuration database with unlimited entries. This specific vulnerability revolves around the domain ownership transition of Xenstore nodes after a guest VM is removed and the inadequacy of safety checks in such scenarios.

Let’s break this down in simple terms and see not just how it happens, but why it matters for system admins and cloud users.

What Is Xenstore?

Xenstore is a critical part of the Xen Hypervisor – it’s a database used for inter-VM communication and configuration data sharing. Each VM (guest domain) gets its own portion of Xenstore to store settings, state, and other meta-data.

Xenstore maintains *ownership*: each node (key/value pair) is “owned” by a domain (the VM that created it).

Where Did Things Go Wrong?

The background here starts with XSA-322, an earlier vulnerability. The fix for XSA-322 introduced a rule: If a domain is deleted, all Xenstore entries it owned are now assigned to Dom (the privileged management VM).

The problem? Dom’s node count isn’t quota-limited – the only quotas are for unprivileged guests.

The Flaw

By engineering the sequence of node creation, deletion, and rebooting, two cooperating malicious guests can use Dom as a dumping ground for excessive nodes, creating conditions for a *denial of service* or exhausting system resources.

Step-by-Step: The Exploit Method

Here’s how this works in practice. Let’s call the malicious guests DomainA and DomainB.

1. DomainA shares access: DomainA configures permissions so DomainB can write nodes into DomainA’s portion of Xenstore.
2. DomainB spams nodes: DomainB connects to Xenstore and creates lots of nodes under DomainA’s tree.
3. DomainB reboots: Upon DomainB’s exit or crash, its own nodes are cleaned up. But the nodes created in DomainA’s tree aren’t.
4. DomainA is removed: If DomainA is deleted or rebooted, all nodes it “owns” (the nodes DomainB created, thanks to step 1) are now assigned to Dom.
5. Dom storage fills up: Rinse and repeat – do this with new guest pairs, and Dom gets an unlimited number of Xenstore nodes because Dom isn’t subject to quota limits.

Result: Any limit on node count meant to stop guests from breaking things can be sidestepped – guests can “leak” node ownership into Dom, filling up Xenstore indefinitely.

Code Snippet: Abusing Xenstore with Python

To see this in action, here’s a conceptual Python snippet using the xs tool (assuming access rights are set up):

import subprocess

def spam_xenstore_nodes(prefix, count):
    for i in range(count):
        # Writes a new node under /local/domain/<target_domain_id>/<key>
        key = f"/local/domain/{prefix}/evilnode{i}"
        value = "attack"
        subprocess.run(['xs', 'write', key, value])

# Set up permissions so domain B can write to domain A's tree
# Then, from domain B:
spam_xenstore_nodes(target_domain_id, 10000)

*Note:* The real exploit needs control over Xenstore permissions, which privileged guests or paravirtualized toolstacks may achieve.

Original References

- XSA-423 – Xen Security Advisory
- XSA-322 – Prior related advisory
- CVE page at MITRE

The issue centers on two oversights

1. Node Ownership Migration: When a domain is deleted, its nodes switch ownership to Dom, but this ignores the original intent for the quota system, side-stepping guest accountability.
2. Unlimited Privileges for Dom: No limit exists for Dom in Xenstore, so malicious use escalates quickly.

Fixes & Mitigations

The developers released XSA-423 to address this class of attacks. Administrators are urged to:

Conclusion

CVE-2022-42323 offers a classic example of how interconnected controls, such as *ownership* and *quota enforcement*, must be considered together in virtualized infrastructures. Two “ordinary” guests, by carefully manipulating node ownership and rebooting, can fill Dom’s Xenstore with junk, putting the stability of the entire host at risk.

Stay patched. Monitor for unexpected Xenstore node growth. And never assume “privileged” means “infallible.”


*For more technical details, see the official Xen advisory.*

Timeline

Published on: 11/01/2022 13:15:00 UTC
Last modified on: 11/28/2022 20:12:00 UTC