Vulnerabilidades

Se presenta un campo de longitud no comprobado en UBoot. La implementación de U-Boot DFU no vincula el campo de longitud en los paquetes de configuración de descarga de USB DFU, y no verifica que la dirección de transferencia sea correspondida con el comando especificado. En consecuencia, si un atacante físico diseña un paquete de configuración de descarga USB DFU con una "wLength" superior a 4096 bytes, puede escribir más allá del búfer de petición asignado a la pila.

HashiCorp Consul y Consul Enterprise versiones hasta la 1.11.8, 1.12.4, y 1.13.1, no comprueban los valores múltiples de SAN URI en un CSR en el endpoint RPC interno, permitiendo un aprovechamiento del acceso privilegiado para omitir las intenciones de malla de servicio. Corregido en 1.11.9, 1.12.5 y 1.13.2".

Existe una escritura de memoria fuera de los límites del montón en FFMPEG desde la versión 5.1. El cálculo del tamaño en `build_open_gop_key_points()` recorre todas las entradas del bucle y añade `sc->ctts_data[i].count` a `sc->sample_offsets_count`. Esto puede conducir a un desbordamiento de enteros que resulta en una pequeña asignación con `av_calloc()`. Un atacante puede provocar la ejecución remota de código a través de un archivo mp4 malicioso. Recomendamos actualizar el commit c953baa084607dd1d84c3bfcce3cf6a87c3e6e05

Se ha encontrado un problema en PBC versiones hasta 27-8-2022. Se ha detectado un problema SEGV en la función pbc_wmessage_integer en el archivo src/wmessage.c:137.

En JetBrains TeamCity versiones anteriores a 2022.04.4, las variables de entorno de tipo "password" podían registrarse cuando era usado un ejecutable Perforce personalizado

Se presenta una lectura de memoria arbitraria dentro del BPF del Kernel de Linux - Las constantes proporcionadas para rellenar los punteros en los structs pasados a bpf_sys_bpf no son verificados y pueden apuntar a cualquier lugar, incluyendo la memoria que no es propiedad de BPF. Un atacante con CAP_BPF puede leer arbitrariamente la memoria de cualquier parte del sistema. Recomendamos actualizar el commit pasado 86f44fcec22c

Apache Pulsar Brokers and Proxies crean un Pulsar Admin Client interno que no verifica los certificados TLS de los compañeros, incluso cuando tlsAllowInsecureConnection está deshabilitado por medio de la configuración. Las conexiones HTTPS intra-clúster y de geo-replicación del Pulsar Admin Client son vulnerables a ataques de tipo man in the middle, que podrían filtrar datos de autenticación, datos de configuración y cualquier otro dato enviado por estos clientes. Un atacante sólo puede aprovecharse de esta vulnerabilidad al tomar el control de una máquina "entre" el cliente y el servidor. El atacante debe entonces manipular activamente el tráfico para llevar a cabo el ataque. Este problema afecta a Apache Pulsar Broker y Proxy versiones 2.7.0 a 2.7.4; 2.8.0 a 2.8.3; 2.9.0 a 2.9.2; 2.10.0; 2.6.4 y anteriores.

Una verificación del nombre de host TLS no puede habilitarse en Pulsar Brokers Java Client, Pulsar Brokers Java Admin Client, Pulsar WebSocket Proxys Java Client, Pulsar Proxys Admin Client, dejando las conexiones intra-clúster y las conexiones de geo-replicación vulnerables a ataques de tipo man in the middle, que podrían filtrar credenciales, datos de configuración, datos de mensajes y cualquier otro dato enviado por estos clientes. La vulnerabilidad es tanto para el protocolo pulsar+ssl como para HTTPS. Un atacante sólo puede aprovecharse de esta vulnerabilidad al tomar el control de una máquina "entre" el cliente y el servidor. El atacante debe entonces manipular activamente el tráfico para llevar a cabo el ataque al proporcionar al cliente un certificado criptográficamente válido para un host no relacionado. Este problema afecta a Apache Pulsar Broker, Proxy y WebSocket Proxy versiones 2.7.0 a 2.7.4; 2.8.0 a 2.8.3; 2.9.0 a 2.9.2; 2.10.0; 2.6.4 y anteriores.

El retraso en la verificación del nombre de host TLS en el cliente Java Pulsar y Pulsar Proxy hace que cada cliente sea vulnerable a un ataque de hombre en el medio. Las conexiones del Cliente Java Pulsar al Broker/Proxy Pulsar y las conexiones del Proxy Pulsar al Broker Pulsar son vulnerables. Los datos de autenticación son enviados antes de verificar que el certificado TLS del servidor coincide con el nombre del host, lo que significa que los datos de autenticación podrían estar expuestos a un atacante. Un atacante sólo puede aprovecharse de esta vulnerabilidad al tomar el control de una máquina "entre" el cliente y el servidor. El atacante debe entonces manipular activamente el tráfico para llevar a cabo el ataque al proporcionar al cliente un certificado criptográficamente válido para un host no relacionado. Como el cliente envía datos de autenticación antes de llevar a cabo la verificación del nombre del host, un atacante podría acceder a los datos de autenticación del cliente. El cliente acaba cerrando la conexión cuando verifica el nombre de host e identifica que el nombre de host objetivo no coincide con un nombre de host en el certificado. Como el cliente acaba cerrando la conexión, el valor de los datos de autenticación interceptados depende del método de autenticación usado por el cliente. Los métodos de autenticación basados en tokens y de nombre de usuario/contraseña son vulnerables porque los datos de autenticación pueden usarse para suplantar al cliente en una sesión independiente. Este problema afecta a Apache Pulsar Java Client versiones 2.7.0 a 2.7.4; 2.8.0 a 2.8.3; 2.9.0 a 2.9.2; 2.10.0; 2.6.4 y anteriores.

Una vulnerabilidad de comprobación de entrada inapropiada en el componente Proxy de Apache Pulsar permite a un atacante realizar intentos de conexión TCP/IP que son originados en la dirección IP del Proxy Pulsar. Cuando es usado el componente Proxy de Apache Pulsar, es posible intentar abrir conexiones TCP/IP a cualquier dirección IP y puerto al que pueda conectarse el Proxy de Pulsar. Un atacante podría usar esto para realizar ataques DoS que sean originados desde la dirección IP del Pulsar Proxy. No se ha detectado que la autenticación del Pulsar Proxy pueda ser omitida. El atacante tendrá que tener un token válido para un Pulsar Proxy debidamente protegido. Este problema afecta a Apache Pulsar Proxy versiones 2.7.0 a 2.7.4; 2.8.0 a 2.8.2; 2.9.0 a 2.9.1; 2.6.4 y anteriores.

Una Fijación de Sesión en el repositorio de GitHub ikus060/rdiffweb versiones anteriores a 2.4.7.<br />

netlify-ipx es una optimización de imágenes bajo demanda para Netlify usando ipx. En las versiones anteriores a la 1.2.3, un atacante puede saltarse la lista de permisos del dominio de la imagen de origen mediante el envío de encabezados especialmente diseñadas, causando que el administrador cargue y devuelva imágenes arbitrarias. Dado que la respuesta es almacenada en caché de forma global, esta imagen será servida a visitantes sin necesidad de establecer esos encabezados. El ataque de tipo XSS puede lograrse al solicitar un SVG malicioso con scripts insertados, que luego será servido desde el dominio del sitio. Tenga en cuenta que esto no es aplicado a imágenes cargadas en "(img)" ya que los scripts no son ejecutados en este contexto. La URL de la imagen puede establecerse en el encabezado independientemente de la URL de la petición, lo que significa que cualquier imagen del sitio que no haya sido previamente almacenada en la caché puede ser envenenada. Este problema ha sido corregido en la versión 1.2.3. Como mitigación, el contenido almacenado en la caché puede borrarse al volver a desplegar el sitio.