Edwin Török

قد تؤدي مشكلات متعددة في XAPI إلى حدوث هجوم «رفض الخدمة» (DoS). أولاً، في حين أن تحديثات قاعدة البيانات تعمل على تنقية سلاسل الإدخال، فإن عملية إنشاء الإشعارات تستخدم مدخلات غير منقاة، مما قد يتسبب في إنهاء مؤشر ترابط أحداث قاعدة البيانات وتوقف المعالجة. ثانيًا، يؤدي التباين بين مشفر UTF-8 (مواصفات Unicode الإصدار 3.0) والمكتبات الداخلية الأخرى (مواصفات Unicode الإصدار 3.1) إلى قبول سلاسل معينة وتخزينها في قاعدة البيانات، مما يمنع لاحقًا تحميل قاعدة البيانات. ثالثًا، هناك نقص في تنقية المدخلات الخاصة بتحديثات Map/Set على الكائنات داخل قاعدة البيانات.

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.