Vulnerabilidades

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.

Arvados es una plataforma de código abierto para administrar y analizar big data biomédico. En versiones anteriores a 2.4.3, cuando eran usados Módulos de Autenticación Portátiles (PAM) para la autenticación de usuarios, si un usuario presentaba credenciales válidas pero la cuenta estaba deshabilitada o no tenía permiso para acceder al host (como una contraseña caducada), seguía siendo aceptada para acceder a Arvados. Otros métodos de autenticación (LDAP, OpenID Connect) soportados por Arvados no están afectados por este fallo. Este problema está parcheado en versión 2.4.3. La mitigación a este problema es migrar a un método de autenticación diferente soportado por Arvados, como LDAP.

En versión 0.10.0 o en versiones anteriores de Apache Pinot, el punto final de consulta de Pinot y la capa de ingestión en tiempo real presentan una vulnerabilidad en entornos no protegidos debido al soporte de una función groovy. Para evitar esto, hemos deshabilitado el soporte de la función groovy por defecto desde la versión 0.11.0 de Pinot. Véase https://docs.pinot.apache.org/basics/releases/0.11.0

Parse Server es un backend de código abierto que puede desplegarse en cualquier infraestructura que pueda ejecutar Node.js. En versiones anteriores a 4.10.16, o desde la 5.0.0 a 5.2.6, la comprobación del ID de la aplicación del adaptador de autenticación para _Facebook_ y _Spotify_ puede ser omitida. Las configuraciones que permiten a usuarios autenticarse usando el adaptador de autenticación de Parse Server donde "appIds" es establecido como una cadena en lugar de una matriz de cadenas autentican peticiones de una aplicación con un ID de aplicación diferente al especificado en la configuración de "appIds". Para que esta vulnerabilidad pueda ser explotada, un atacante necesita que el proveedor de autenticación le asigne un ID de aplicación que sea un subconjunto del ID de aplicación configurado en el lado del servidor. Este problema está parcheado en versiones 4.10.16 y 5.2.7. No se presentan mitigaciones conocidas.