Edwin Török

Multiple issues in XAPI can lead to a Denial of Service. First, while updates to the database sanitize input strings, the notification generation process uses unsanitized input, which can cause the database event thread to terminate and stop processing. Second, a discrepancy between the UTF-8 encoder (Unicode spec v3.0) and other internal libraries (Unicode spec v3.1) allows certain strings to be accepted and stored in the database, which subsequently prevents the database from being loaded. Third, there is a lack of input sanitization for Map/Set updates on objects within the database.

An issue was discovered in Xen XAPI where certain xenstore keys provide feedback from the guest and are watched by toolstack, specifically by xenopsd. The watching logic in xenopsd sends one RPC update containing all data any time a single xenstore key is updated, resulting in O(N^2) time complexity. Furthermore, message-switch retains recent RPC messages for diagnostic purposes, yielding O(M*N) space complexity. A buggy or malicious guest can cause unreasonable memory usage in dom0, resulting in a host denial of service. The quantity of memory a single guest can monopolize is bounded by xenstored quota, which is fairly large, believed to be in excess of 1G per malicious guest.

The issue is related to the oxenstored process of the Xen hypervisor, which is associated with unbounded memory allocation. Exploitation of this issue can allow an attacker to cause a denial of service. In oxenstored, a node owner could give a node away, but node ownership has quota implications. Any guest can run another guest out of quota or create an unbounded number of nodes owned by dom0, thus running xenstored out of memory. A malicious guest administrator can cause a denial of service against a specific guest or against the whole host. All systems using oxenstored are vulnerable.

The issue is related to the implementation of Ocaml xenstored in Xen, where the internal representation of the tree has special cases for the root node. Unfortunately, permissions were not checked for certain operations on the root node, allowing unprivileged guests to get and modify permissions, list, and delete the root node. This can lead to a host-wide denial of service if the whole xenstore tree is deleted. Achieving xenstore write access is also possible. All systems using oxenstored are vulnerable, while systems using C xenstored are not.

An issue was discovered in Xen where a guest may access xenstore paths via absolute paths containing a full pathname, or via a relative path, which implicitly includes `/local/domain/$DOMID` for their own domain id. Management tools must access paths in guests' namespaces, necessarily using absolute paths. oxenstored imposes a pathname limit that is applied solely to the relative or absolute path specified by the client. Therefore, a guest can create paths in its own namespace which are too long for management tools to access. Depending on the toolstack in use, a malicious guest administrator might cause some management tools and debugging operations to fail. For example, a guest administrator can cause "xenstore-ls -r" to fail. However, a guest administrator cannot prevent the host administrator from tearing down the domain. All systems using oxenstored are vulnerable.

The issue allows remote servers to cause a denial of service (crash) via a reply with an empty DNS address that has an (1) A or (2) AAAA record defined locally.