Vulnerabilidades

Se detectó un problema en Xen versiones hasta 4.14.x. Cuando se activa un reloj de Xenstore, el cliente de Xenstore que registró el reloj recibirá un mensaje de Xenstore que contiene la ruta de la entrada de Xenstore modificada que activó el reloj y la etiqueta que estaba especificada al registrar el reloj. Cualquier comunicación con xenstored es realizada por medio de mensajes de Xenstore, que constan de un encabezado de mensaje y la carga útil. La longitud de la carga útil está limitada a 4096 bytes. Cualquier petición a xenstored resulta en una respuesta con una carga útil superior a 4096 bytes que dará como resultado un error. Cuando se registra un reloj, el límite de longitud de la carga útil se aplica a la longitud combinada de la ruta observada y la etiqueta especificada. Debido a que los relojes de una ruta específica son también activados para todos los nodos debajo de esa ruta, la carga útil de un mensaje de evento de vigilancia puede ser más larga que la carga útil necesaria para registrar la vigilancia. Un invitado malicioso que registra un reloj usando una etiqueta muy grande (es decir, con una longitud de carga útil de la operación de registro cercana al límite de 4096 bytes) puede causar la generación de eventos de reloj con una longitud de carga superior a 4096 bytes, al escribir en las entradas de Xenstore por debajo en la ruta vigilada. Esto resultará en una condición de error en xenstored. Este error puede resultar en una desreferencia del puntero NULL, conllevando a un bloqueo de xenstored. Un administrador invitado malicioso puede causar que xenstored se bloquee, conllevando a una denegación de servicio. Siguiendo con un bloqueo de xenstored, los dominios pueden continuar ejecutándose, pero las operaciones de administración serán imposibles. Solo C xenstored está afectado, oxenstored no está afectado

Se detectó un problema en Xen versiones hasta 4.14.x. Xenstored y los invitados se comunican por medio de una página de memoria compartida usando un protocolo específico. Cuando un invitado viola este protocolo, xenstored interrumpirá la conexión con ese invitado. Desafortunadamente, esto se hace simplemente eliminando al invitado de la administración interna de xenstored, resultando en las mismas acciones como si el invitado hubiera sido destruido, incluyendo el envío de un evento @releaseDomain. Los eventos de @releaseDomain no dicen que el invitado ha sido eliminado. Todos los observadores de este evento deben mirar los estados de todos los invitados para encontrar al invitado que ha sido eliminado. Cuando @releaseDomain es generada debido a una violación del protocolo xenstored del dominio, porque el invitado aún se está ejecutando, los observadores no reaccionarán. Más tarde, cuando el invitado sea realmente destruido, xenstored ya no lo tendrá almacenado en su base de datos interna, por lo que no más eventos @releaseDomain serán enviados. Esto puede conllevar a un dominio zombi; Las asignaciones de la memoria de ese invitado no serán eliminadas debido a una falta de evento. Este dominio zombie será limpiado solo después de que otro dominio sea destruido, ya que eso activará otro evento @releaseDomain. Si el modelo de dispositivo del invitado que violó el protocolo de Xenstore se está ejecutando en un dominio stub, un caso de uso de la memoria previamente liberada podría ocurrir en xenstored, después de haber eliminado al invitado de su base de datos interna, resultando posiblemente en un bloqueo de xenstored. Un invitado malicioso puede bloquear los recursos del host durante un período después de su propia muerte. Los invitados con un modelo de dispositivo de dominio stub pueden eventualmente bloquearse en xenstored, resultando en una denegación de servicio más grave (la prevención de cualquier otra operación de administración de dominio). Solo la variante C de Xenstore está afectada; la variante Ocaml no está afectada. Solo los invitados de HVM con un modelo de dispositivo falso pueden causar una DoS grave

Se detectó un problema en Xen versiones hasta 4.14.x. Un invitado puede acceder a las rutas de xenstore por medio de rutas absolutas que contienen un nombre de ruta completo, o por medio de una ruta relativa, que implícitamente incluye /local/ domain/$DOMID para su propio ID de dominio. Las herramientas de administración deben acceder a las rutas en los espacios de nombres de los invitados, necesariamente usando rutas absolutas. oxenstored impone un límite de nombre de ruta que es aplicado únicamente a la ruta relativa o absoluta especificada por el cliente. Por lo tanto, un invitado puede crear rutas en su propio espacio de nombre que son demasiado largas para que las herramientas de administración accedan. Dependiendo de la toolstack en uso, un administrador invitado malicioso puede causar que algunas herramientas de administración y operaciones de depuración presenten un fallo. Por ejemplo, un administrador invitado puede causar que "xenstore-ls -r" presente un fallo. Sin embargo, un administrador invitado no puede impedir que el administrador del host elimine el dominio. Todos los sistemas utilizados en oxenstored son vulnerables. La construcción y el uso de oxenstored es el valor predeterminado en la distribución Xen previa, si el compilador Ocaml está disponible. Los sistemas que usan C xenstored no son vulnerables

*** Pendiente de traducción *** Rejected reason: DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: The CNA or individual who requested this candidate did not associate it with any vulnerability during 2020. Notes: none

*** Pendiente de traducción *** Rejected reason: DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: The CNA or individual who requested this candidate did not associate it with any vulnerability during 2020. Notes: none

*** Pendiente de traducción *** Rejected reason: DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: The CNA or individual who requested this candidate did not associate it with any vulnerability during 2020. Notes: none

*** Pendiente de traducción *** Rejected reason: DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: The CNA or individual who requested this candidate did not associate it with any vulnerability during 2020. Notes: none

Se detectó un problema en Xen versiones hasta 4.14.x. Ninguna implementación de xenstore lleva a cabo comprobaciones de permisos al reportar un evento de observación de xenstore. Un administrador invitado puede visualizar el nodo xenstored root, lo que causará notificaciones para cada clave diseñada, modificada y eliminada. Un administrador invitado también puede usar los relojes especiales, que causarán una notificación cada vez que el dominio es creado y destruido. Los datos pueden incluir: número, tipo y domids de otras VM; existencia y domids de dominios de controladores; número de interfaces virtuales, dispositivos de bloque, vcpus; existencia de framebuffers virtuales y su estilo de backend (por ejemplo, existencia de servicio VNC); UUID de Xen VM para otros dominios; información de sincronización sobre la creación del dominio y la configuración del dispositivo; y algunas sugerencias sobre el aprovisionamiento de backend de máquinas virtuales y sus dispositivos. Los eventos de vigilancia no contienen valores almacenados en xenstore, solo nombres de claves. Un administrador invitado puede observar eventos no confidenciales del ciclo de vida del dispositivo y del dominio relacionados con otros invitados. Esta información permite tener una idea de la configuración general del sistema (incluido el número y la naturaleza general de otros invitados) y la configuración de otros invitados (incluido el número y la naturaleza general de los dispositivos de otros invitados). Esta información puede resultar comercialmente interesante o facilitar otros ataques. No se cree que haya exposición de datos confidenciales. Específicamente, no se exponen las contraseñas de VNC, los números de puerto, los nombres de ruta en los sistemas de archivos del host e invitado, las claves criptográficas o los datos internos del invitado

Se detectó un problema en Xen versiones hasta 4.14.x. Los derechos de acceso de los nodos de Xenstore son per domid. Desafortunadamente, los derechos de acceso concedidos existentes no son eliminados cuando un dominio ha sido destruido. Esto significa que un nuevo dominio creado con el mismo domid heredará los derechos de acceso a los nodos de Xenstore de los dominios anteriores con el mismo domid. Debido a que todas las entradas de Xenstore de un invitado por debajo /local/domain/(domid) han sido eliminadas por las herramientas Xen, cuando un invitado es destruido; solo las entradas Xenstore de otros invitados que aún se estén ejecutando están afectadas. Por ejemplo, un dominio invitado recién creado puede ser capaz de leer información confidencial que perteneciera a un dominio invitado previamente existente. Ambas implementaciones de Xenstore (C y Ocaml) son vulnerables

Se detectó un problema en Xen versiones hasta 4.14.x. Los nodos de xenstore tienen una propiedad. En oxenstored, un propietario podría entregar un nodo incesantemente. Sin embargo, la propiedad del nodo presenta implicaciones de cuota. Cualquier invitado puede ejecutar otro invitado fuera de la cuota o crear un número ilimitado de nodos propiedad de dom0, ejecutando xenstored sin memoria. Un administrador invitado malicioso puede causar una denegación de servicio contra un invitado específico o contra todo el host. Todos los sistemas que utilizan oxenstored son vulnerables. La construcción y el uso de oxenstored es el valor predeterminado en la distribución Xen ascendente, si el compilador Ocaml está disponible. Los sistemas que utilizan C xenstored no son vulnerables

Se detectó un problema en Xen XAPI antes del 15/12/2020. Determinadas claves de xenstore proporcionan comentarios del invitado y, por lo tanto, son supervisadas por toolstack. Específicamente, las claves son supervisadas por xenopsd y los datos son reenviados por medio de RPC mediante message-switch hacia xapi. La lógica de observación en xenopsd envía una actualización RPC que contiene todos los datos, cada vez que una sola clave de xenstore es actualizada y, por lo tanto, presenta una complejidad de tiempo O(N^2). Además, message-switch conserva los mensajes RPC recientes (actualmente 128) con propósitos de diagnóstico, lo que genera una complejidad de espacio O(M*N). La cantidad de memoria que un solo invitado puede monopolizar está limitada por la cuota almacenada en xen, pero la cuota es bastante grande. Se cree que supera 1G por invitado malicioso. En la práctica, esto se manifiesta como una denegación de servicio del host, ya sea a través de message-switch contra el intercambio, o mediante OOM por completo, dependiendo de la configuración de dom0. (No existen cuotas en xenopsd para limitar la cantidad de claves que resultan en tráfico RPC.) Un invitado con errores o malicioso puede causar un uso de memoria irrazonable en dom0, resultando en una denegación de servicio del host. Todas las versiones de XAPI son vulnerables. Los sistemas que no están usando la toolstack de XAPI no son vulnerables

Se detectó un problema en Xen versiones hasta 4.14.x. En la implementación de Ocaml xenstored, la representación interna del árbol tiene casos especiales para el nodo root, porque este nodo no tiene padre. Desafortunadamente, no fueron comprobados los permisos para determinadas operaciones en el nodo root. Los invitados no privilegiados pueden obtener y modificar permisos, enumerar y eliminar el nodo root. (Eliminar todo el árbol de xenstore es una denegación de servicio en todo el host). Lograr el acceso de escritura a xenstore también es posible. Todos los sistemas que usan oxenstored son vulnerables. La construcción y el uso de oxenstored es el valor predeterminado en la distribución Xen previa, si el compilador Ocaml está disponible. Los sistemas que utilizan C xenstored no son vulnerables