CVE-2020-29481 in Xen
Summary
by MITRE • 12/15/2020
An issue was discovered in Xen through 4.14.x. Access rights of Xenstore nodes are per domid. Unfortunately, existing granted access rights are not removed when a domain is being destroyed. This means that a new domain created with the same domid will inherit the access rights to Xenstore nodes from the previous domain(s) with the same domid. Because all Xenstore entries of a guest below /local/domain/ are being deleted by Xen tools when a guest is destroyed, only Xenstore entries of other guests still running are affected. For example, a newly created guest domain might be able to read sensitive information that had belonged to a previously existing guest domain. Both Xenstore implementations (C and Ocaml) are vulnerable.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 12/18/2020
The vulnerability described in CVE-2020-29481 represents a critical access control flaw in the Xen hypervisor's Xenstore implementation that persists across domain lifecycle operations. This issue affects Xen versions through 4.14.x and fundamentally undermines the security model that relies on domain isolation. The core problem lies in how Xenstore manages access permissions for domain-specific nodes, where access rights are traditionally associated with domain identifiers or domid values. When a domain is destroyed, the system fails to properly revoke the access rights that were previously granted to that domain's xenstore nodes, creating a persistent security gap that can be exploited by subsequent domains sharing the same domid.
The technical flaw stems from improper cleanup mechanisms during domain destruction processes within the Xen hypervisor's storage subsystem. Specifically, while Xen tools correctly delete all xenstore entries located under /local/domain/ for the destroyed guest domain, they fail to properly invalidate or remove the access control permissions that were previously established for that domain's xenstore nodes. This creates a scenario where a newly created domain with the same domid inherits not only the domain's identity but also the inherited access rights from previous domains that occupied that same identifier. The vulnerability affects both the C and Ocaml implementations of Xenstore, indicating a systemic architectural weakness rather than an isolated implementation bug.
The operational impact of this vulnerability extends beyond simple information disclosure to potentially enable cross-domain privilege escalation and data leakage attacks. When a malicious domain is created with a previously used domid, it can potentially access xenstore entries that were intended to be isolated to the previous domain, including sensitive configuration data, guest state information, or other confidential parameters. This inheritance of access rights can lead to information disclosure attacks where a newly created domain gains unauthorized access to secrets, credentials, or system parameters that belonged to the previous domain. The vulnerability is particularly concerning in multi-tenant environments where domain reuse is common and where the exposure of one domain's xenstore data could compromise the security of other running domains.
This vulnerability maps directly to CWE-284, which addresses inadequate access control mechanisms, and aligns with ATT&CK technique T1068, which covers "Exploitation for Privilege Escalation." The flaw represents a failure in proper resource cleanup and access control management during domain lifecycle transitions, creating a persistent security boundary violation. Organizations running Xen hypervisors in production environments should immediately implement mitigations including disabling domain reuse where possible, implementing additional access control layers, and ensuring proper xenstore permission cleanup during domain destruction. The vulnerability demonstrates the critical importance of proper resource management in virtualization platforms and highlights the need for comprehensive security testing of lifecycle operations in hypervisor implementations.