Vulnerabilidades

En JetBrains Hub versiones anteriores a 2019.1.11738, la enumeración de nombres de usuario fue posible mediante la recuperación de contraseña.

JetBrains MPS versiones anteriores a 2019.2.2, expuso los puertos de escucha en la red.

En JetBrains TeamCity versiones anteriores a 2019.1.2, un acceso podría ser conseguido al historial de compilaciones de una configuración de compilación eliminada en algunas circunstancias.

En JetBrains TeamCity versiones anteriores a 2019.1.4, una Deserialización de Java no segura podría permitir una ejecución de código remota.

JetBrains IntelliJ IDEA versiones anteriores a 2019.2, permite la escalada de privilegios de un usuario local, conllevando potencialmente a una ejecución de código arbitrario.

Jupyter Notebook versiones anteriores a 5.5.0, no utiliza un encabezado CSP para tratar los archivos servidos como pertenecientes a un origen separado. Así, por ejemplo, se puede colocar una carga XSS en un documento SVG.

Se detectó un problema en Xen versiones hasta 4.12.x, permitiendo a atacantes alcanzar privilegios de Sistema Operativo host por medio de DMA en una situación donde un dominio no confiable tiene acceso a un dispositivo físico. Esto se presenta porque pasado por medio de dispositivos PCI puede corromper la memoria del host después de la desasignación. Cuando un dispositivo PCI es asignado a un dominio no confiable, es posible que ese dominio programe el dispositivo a DMA en una dirección arbitraria. El IOMMU es utilizado para proteger el host de DMA malicioso al asegurar que las direcciones del dispositivo solo puedan apuntar a la memoria asignada al invitado. Sin embargo, cuando el dominio invitado es derribado o el dispositivo es desasignado, el dispositivo es asignado de nuevo a dom0, permitiendo que cualquier DMA en vuelo apunte potencialmente a datos críticos del host. Un dominio no confiable con acceso a un dispositivo físico puede DMA en la memoria del host, lo que conlleva a la escalada de privilegios. Solo los sistemas donde los invitados tienen acceso directo a dispositivos físicos capaces de DMA (atravesar el PCI) son vulnerables. Los sistemas que no utilizan la transferencia PCI no son vulnerables.

Se detectó un problema en Xen versiones hasta 4.12.x, permitiendo a usuarios del SO invitado de PV de 32 bits alcanzar privilegios del SO invitado mediante la instalación y el uso de descriptores. Se presenta una falta la comprobación de límite de la tabla descriptor en la emulación PV x86. Al emular determinadas operaciones de invitados PV, el código de emulación realiza los accesos a la tabla de descriptores. Dichos accesos deben respetar los límites especificados por parte del invitado, a menos que se garantice que fallen en tal caso. Sin esto, la emulación de llamadas de modo de usuario invitado de 32 bits por medio de las puertas de llamada permitiría la instalación del modo de usuario invitado y luego usaría los descriptores de su elección, siempre que el kernel invitado no instalara un LDT. (La mayoría de los sistemas operativos no instalan ningún LDT por defecto). El modo de usuario invitado PV de 32 bits puede elevar sus privilegios a los del kernel invitado. Las versiones de Xen de por lo menos 3.2 en adelante están afectadas. Solo el modo de usuario invitado PV de 32 bits puede aprovechar esta vulnerabilidad. HVM, PVH, así como los invitados PV de 64 bits no pueden explotar esta vulnerabilidad. Los sistemas ARM no están afectados.

Se detectó un problema en Xen versiones hasta 4.12.x, permitiendo a usuarios del sistema operativo invitado de ARM causar una denegación de servicio por medio de una hipercall Xmapme_add_to_physmap. p2m-)max_mapped_gfn es utilizado por las funciones p2m_resolve_translation_fault() y p2m_get_entry() para comprobar trama física del invitado. El resto del código en las dos funciones asumirá que existe una tabla root válida y lo comprobará con BUG_ON(). La función p2m_get_root_pointer() ignorará los bits superiores no utilizados de una trama física de invitado. Esto significa que la función p2m_set_entry() renombrará la trama. Sin embargo, p2m-)max_mapped_gfn será actualizada utilizando la trama original. Sería posible establecer p2m-)max_mapped_gfn lo suficientemente alto como para cubrir una trama que conllevaría a p2m_get_root_pointer() a devolver NULL en p2m_get_entry() y p2m_resolve_translation_fault(). Adicionalmente, la comprobación de saneamiento en p2m-)max_mapped_gfn está por un paso permitiendo que el "highest mapped + 1" sea considerado válido. Sin embargo, p2m_get_root_pointer() devolverá NULL. El problema podría desencadenarse con una hipercall especialmente diseñada XENMEM_add_to_physmap{, _batch} seguido de un acceso a una dirección (por medio de hipercall o acceso directo) que pasa la comprobación de saneamiento pero hace que la función p2m_get_root_pointer() devuelva NULL. Un administrador invitado malicioso puede causar un bloqueo del hipervisor, resultando en una Denegación de Servicio (DoS). Xen versión 4.8 y mas recientes son vulnerables. Solo los sistemas Arm son vulnerables. Los sistemas x86 no están afectados.

Se detectó un problema en Xen versiones hasta 4.12.x, permitiendo a usuarios del sistema operativo invitado PV de x86 causar una denegación de servicio por medio de una hipercall de VCPUOP_initialise. hypercall_create_continuation() es una función variadic que utiliza una cadena de formato tipo printf para interpretar sus parámetros. El manejo de errores para un carácter de formato incorrecto fue realizado utilizando BUG(), que bloquea a Xen. Una ruta, por medio de una hypercall VCPUOP_initialise, tiene un carácter de formato incorrecto. El BUG() puede ser golpeado si VCPUOP_initialise es ejecutado durante un período de tiempo suficientemente largo para que una continuación sea creada. Los invitados maliciosos pueden causar un bloqueo del hipervisor, resultando en una Denegación de Servicio (DoS). Xen versiones 4.6 y más recientes son vulnerables. Las versiones de Xen 4.5 y anteriores no son vulnerables. Solo los invitados de PV x86 pueden explotar la vulnerabilidad. Los invitados de HVM y PVH, e invitados en sistemas ARM, no pueden explotar la vulnerabilidad.

Se detectó un problema en Xen versiones hasta 4.12.x, permitiendo a usuarios del sistema operativo invitado PV de x86 alcanzar privilegios de sistema operativo host mediante el aprovechamiento de las condiciones de carrera en las operaciones de promoción y degradación de la página. Se presentan problemas con las operaciones de cambio de tipo de PV reiniciables. Para evitar el uso de tablas de páginas shadow para invitados PV, Xen expone las tablas de páginas de hardware actuales al invitado. Para impedir que el invitado modifique directamente estas tablas de páginas, Xen realiza un seguimiento de cómo son usadas las páginas utilizando un sistema de tipos; las páginas deben ser "promoted" antes de ser usadas como una tabla de páginas y "demoted" antes de ser usadas por cualquier otro tipo. Xen también permite promociones "recursive": es decir, un sistema operativo que promociona una página en una tabla de páginas L4 puede terminar haciendo que las páginas se promocionen a L3, lo que a su vez puede causar que las páginas se promocionen a L2, y así sucesivamente. Estas operaciones pueden tomar una cantidad de tiempo arbitrariamente grande y, por lo tanto, deben ser reiniciadas. Desafortunadamente, hacer reiniciables las operaciones de promoción y degradación de tablas de páginas recursivas es increíblemente complejo, y el código contiene varias carreras que, si son activadas, pueden hacer que Xen elimine o retenga conteos de tipos adicionales, lo que potencialmente permite a los invitados conseguir acceso de escritura a las tablas de páginas en uso. Un administrador invitado malicioso de PV puede escalar sus privilegios a los del host. Todos los sistemas x86 con invitados PV no confiables son vulnerables. Los invitados HVM y PVH no pueden ejercer esta vulnerabilidad.

Se detectó un problema en Xen versiones hasta 4.12.x, permitiendo a usuarios del sistema operativo invitado ARM causar una denegación de servicio o alcanzar privilegios mediante el aprovechamiento de la habilitación errónea de interrupciones. Las interrupciones se desenmascaran incondicionalmente en los controladores de excepciones. Cuando se produce una excepción en un sistema ARM que es manejado sin cambiar el nivel del procesador, algunas interrupciones son habilitadas incondicionalmente durante la entrada de la excepción. Por lo tanto, las excepciones que se presentan cuando se enmascaran las interrupciones desenmascararán efectivamente las interrupciones. Un invitado malicioso podría lograr que el código Xen crítico sea ejecutado con interrupciones habilitadas erróneamente. Esto podría conllevar a una corrupción de datos, una denegación de servicio o, posiblemente, una escalada de privilegios. Sin embargo, no se ha identificado una técnica de ataque precisa.