Vulnerabilidades

La página ping del panel de administración en Telmat AccessLog versiones anteriores a 6.0 (TAL_20180415), permite a un atacante conseguir acceso de shell root por medio de una inyección de código autenticado a través de la red.

Untis WebUntis versiones anteriores a 2020.9.6, permite un ataque de tipo XSS en múltiples funciones que almacenan información.

Una administración web de Internal CA de Check Point Security Management anterior a HFA Jumbo HFAs R80.10 Take 278, R80.20 Take 160, R80.30 Take 210, and R80.40 Take 38, puede ser manipulada para ejecutar comandos como un usuario muy privilegiado o un bloqueo, debido a una comprobación débil de la entrada por parte de un administrador de gestión confiable

El mecanismo de autenticación de la API cliente en Pexip Infinity versiones anteriores a 10, permite a atacantes remotos alcanzar privilegios por medio de una petición diseñada.

Una vulnerabilidad de comprobación de certificación de servidor SSL incompleta en la familia de productos de consumo Trend Micro Security 2019 versión (v15), podría permitir a un atacante combinar esta vulnerabilidad con otro ataque para engañar a un cliente afectado para que descargue una actualización maliciosa en lugar de la prevista. CWE-494: Los archivos de actualización no se comprobaron apropiadamente.

Una vulnerabilidad de comprobación de certificación de servidor SSL incompleta en la familia de productos de consumidor Trend Micro Security 2019 versión (v15), podría permitir a un atacante combinar esta vulnerabilidad con otro ataque para engañar a un cliente afectado para que descargue una actualización maliciosa en lugar de la esperada. CWE-295: Comprobación inapropiada del certificado del servidor en la comunicación con el servidor de actualización.

Se detectó un problema en Xen versiones hasta 4.14.x. Se presentan condiciones de carrera de la función evtchn_reset(). Los usos de EVTCHNOP_reset (potencialmente por parte de un invitado en sí mismo) o XEN_DOMCTL_soft_reset (por sí mismo cubierto por XSA-77) pueden conducir a la violación de varias suposiciones internas. Esto puede conllevar a accesos a memoria fuera de los límites o a la activación de comprobaciones de errores. En particular, los invitados de PV x86 pueden elevar su privilegio al del anfitrión. También es posible que el host y el invitado se bloqueen, conllevando a una Denegación de Servicio (DoS). El filtrado de información no se puede descartar. Todas las versiones de Xen desde la 4.5 en adelante son vulnerables. Las versiones 4.4 y anteriores de Xen no son vulnerables.

Se detectó un problema en Xen versiones hasta 4.14.x. Los canales de eventos fuera de límites están disponibles para dominios x86 de 32 bits. El llamado modelo de canal de eventos de 2 niveles impone diferentes límites en el número de canales de eventos utilizables para dominios x86 de 32 bits frente a los de 64 bits o Arm (cualquiera de los dos). Los dominios x86 de 32 bits solo pueden usar 1023 canales, debido al espacio limitado en su estructura de información compartida (entre invitados y Xen), mientras que todos los demás dominios pueden usar hasta 4095 en este modelo. Sin embargo, el registro del límite respectivo durante la inicialización del dominio ha ocurrido en un momento en el que aún se considera que los dominios son de 64 bits, antes de respetar realmente las propiedades del dominio respectivo. En el momento en que los dominios se reconocen como de 32 bits, el límite no logró actualizarse en consecuencia. Debido a este comportamiento inapropiado en Xen, los dominios de 32 bits (incluido el Dominio 0) que prestan servicio a otros dominios pueden observar que las asignaciones de canales de eventos tienen éxito cuando realmente deberían presentar un fallo. El uso posterior de dichos canales de eventos posiblemente conduciría a una corrupción de otras partes de la estructura de información compartida. Un invitado sin privilegios puede hacer que otro dominio, en particular el Dominio 0, se comporte incorrectamente. Esto puede conllevar a una Denegación de servicio (DoS) para todo el sistema. Todas las versiones de Xen desde 4.4 en adelante son vulnerables. Las versiones 4.3 y anteriores de Xen no son vulnerables. Solo los dominios x86 de 32 bits que dan servicio a otros dominios son vulnerables. Los sistemas Arm, así como los dominios x86 de 64 bits, no son vulnerables. Un invitado sin privilegios puede hacer que otro dominio, en particular el Dominio 0, se comporte mal. Esto puede conllevar a una Denegación de servicio (DoS) para todo el sistema. Todas las versiones de Xen desde 4.4 en adelante son vulnerables. Las versiones 4.3 y anteriores de Xen no son vulnerables. Solo los dominios x86 de 32 bits que dan servicio a otros dominios son vulnerables. Los sistemas Arm, así como los dominios x86 de 64 bits, no son vulnerables. Un invitado sin privilegios puede hacer que otro dominio, en particular el Dominio 0, se comporte mal. Esto puede conllevar a una Denegación de Servicio (DoS) para todo el sistema. Todas las versiones de Xen desde 4.4 en adelante son vulnerables. Las versiones 4.3 y anteriores de Xen no son vulnerables. Solo los dominios x86 de 32 bits que dan servicio a otros dominios son vulnerables. Los sistemas Arm, así como los dominios x86 de 64 bits, no son vulnerables.

Se detectó un problema en Xen versiones hasta 4.14.x. Se presenta una carencia de preferencia en evtchn_reset() / evtchn_destroy(). En particular, el modelo de canal de eventos FIFO permite a los invitados tener una gran cantidad de canales de eventos activos simultáneos. Cerrar todos estos (al restablecer todos los canales de eventos o al limpiar después del invitado) puede llevar períodos de tiempo prolongados. Hasta ahora, no había ningún arreglo para la preferencia a intervalos adecuados, lo que permitía que una CPU pasara una cantidad de tiempo casi ilimitada en el procesamiento de estas operaciones. Los kernels invitados maliciosos o con errores pueden montar un ataque de denegación de servicio (DoS) afectando a todo el sistema. Todas las versiones de Xen son vulnerables en principio. Tanto las versiones 4.3 y como las anteriores son vulnerables dependiendo de las características subyacentes del hardware.

Se detectó un problema en Xen versiones hasta 4.14.x. Se presenta una carencia de barreras de memoria al acceder y asignar un canal de eventos. Las estructuras de control de canales de eventos pueden ser accedidas sin lock siempre que el puerto se considere válido. A dicha secuencia le falta una barrera de memoria adecuada (por ejemplo, smp_* mb()) para evitar que tanto el compilador como la CPU reordenen el acceso. Un invitado malicioso puede causar un bloqueo del hypervisor que resulte en una Denegación de Servicio (DoS). Un filtrado de información y una escalada de privilegios no puede ser excluidas. Los sistemas que ejecutan todas las versiones de Xen están afectados. La vulnerabilidad de un sistema dependerá de la CPU y el compilador usados para construir Xen. Para todos los sistemas, la presencia y el alcance de la vulnerabilidad dependen del reordenamiento preciso realizado por el compilador utilizado para compilar Xen. No hemos podido encuestar a los compiladores; en consecuencia, no podemos decir qué compilador (es) podrían producir código vulnerable (con cuales opciones de generación de código). La documentación de GCC sugiere claramente que el reordenamiento es posible. Los sistemas Arm también serán vulnerables si la CPU puede reordenar el acceso a la memoria. Consulte a su proveedor de CPU. Los sistemas x86 solo son vulnerables si un compilador realiza un reordenamiento.

Se detectó un problema en Xen versiones hasta 4.14.x. Existe un manejo inapropiado de la restricción de que los canales de eventos que una vez fueron válidos no pueden volverse no válidos. La lógica en el manejo de las operaciones del canal de eventos en Xen asume que un canal de eventos, una vez válido, no dejará de serlo durante la vida útil de un invitado. Sin embargo, operaciones como el restablecimiento de todos los canales de eventos pueden implicar la disminución de uno de los límites comprobados al determinar la validez. Esto puede provocar que se activen las comprobaciones de errores y que el host se bloquee. Un invitado sin privilegios puede bloquear Xen, conllevando a una Denegación de servicio (DoS) para todo el sistema. Todas las versiones de Xen desde 4.4 en adelante son vulnerables. Las versiones 4.3 y anteriores de Xen no son vulnerables. Solo los sistemas con invitados que no son de confianza y que tienen permitido crear más canales de eventos que el número predeterminado son vulnerables. Este número depende de la arquitectura y el tipo de invitado. Para invitados PV x86 de 32 bits, es 1023; para invitados PV x86 de 64 bits y para todos los invitados ARM, este número es 4095. Los sistemas en los que los invitados que no son de confianza están limitados a menos de este número no son vulnerables. Tome en cuenta que xl y libxl limitan max_event_channels a 1023 de forma predeterminada, por lo que los sistemas que usan exclusivamente xl, libvirt + libxl o su propio conjunto de herramientas basado en libxl, y que no establecen explícitamente max_event_channels, no son vulnerables

Se detectó un problema en Xen versiones hasta 4.14.x. Los kernels invitados de PV x86 pueden experimentar una denegación de servicio a través de SYSENTER. La instrucción de SYSENTER deja varias actividades de saneamiento del estado para el software. Una de las rutas de saneamiento de Xen inyecta un fallo #GP y la entrega incorrectamente dos veces al invitado. Esto causa que el kernel invitado observe un fallo de #GP de privilegios de kernel (generalmente fatal) en lugar de un fallo de #GP de privilegios de usuario (generalmente convertida a SIGSEGV/etc.). El espacio de usuario malicioso o con errores puede bloquear el kernel invitado, lo que resulta en una denegación de servicio de la VM. Todas las versiones de Xen desde 3.2 en adelante son vulnerables. Solo los sistemas x86 son vulnerables. Las plataformas ARM no son vulnerables. Solo los sistemas x86 que admiten la instrucción SYSENTER en modo de 64 bits son vulnerables. Se cree que son CPU de Intel, Centaur y Shanghai. No se cree que las CPU AMD e Hygon sean vulnerables. Solo los invitados PV x86 pueden aprovechar la vulnerabilidad. Los invitados x86 PVH/HVM no pueden aprovechar la vulnerabilidad