Vulnerabilidades

4ipnet EAP-767 v3.42.00 es vulnerable a un control de acceso incorrecto. El dispositivo utiliza el mismo conjunto de credenciales, independientemente de cuántas veces inicie sesión un usuario, el contenido de la cookie permanece sin cambios.

La vulnerabilidad de inyección de comandos descubierta en el dispositivo 4ipnet EAP-767 v3.42.00 dentro de la interfaz web del dispositivo permite a atacantes con credenciales válidas inyectar comandos de shell arbitrarios para que los ejecute el dispositivo con privilegios de root.

Se ha identificado una posible vulnerabilidad de seguridad en el BIOS del sistema para ciertas estaciones de trabajo HP, que podría permitir una escalada de privilegios, la ejecución de código arbitrario o la denegación de servicio. HP está lanzando medidas de mitigación para la posible vulnerabilidad.

Se han identificado vulnerabilidades potenciales en ciertos productos de PC de escritorio HP que utilizan la función HP TamperLock, que podría permitir eludir la detección de intrusiones mediante un ataque físico. HP está lanzando firmware y orientación para mitigar estas posibles vulnerabilidades.

Se han identificado vulnerabilidades potenciales en ciertos productos de PC de escritorio HP que utilizan la función HP TamperLock, que podría permitir eludir la detección de intrusiones mediante un ataque físico. HP está lanzando firmware y orientación para mitigar estas posibles vulnerabilidades.

Un valor predeterminado inseguro para permitir UEFI Shell en EDK2 se dejó habilitado en EDK2 de Ubuntu. Esto permite que un atacante residente en el sistema operativo omita el arranque seguro.

Un valor predeterminado inseguro para permitir UEFI Shell en EDK2 se dejó habilitado en LXD. Esto permite que un atacante residente en el sistema operativo omita el arranque seguro.

Existe una vulnerabilidad de inyección de comandos donde un atacante remoto autenticado con privilegios de administrador en la aplicación Security Center podría modificar los parámetros de registro, lo que podría conducir a la ejecución de código arbitrario en el host de Security Center.

Existe una vulnerabilidad de inyección de HTML en la que un atacante remoto autenticado con privilegios de administrador en la aplicación Security Center podría modificar los parámetros del repositorio, lo que podría provocar ataques de redirección de HTML.

Squid es un proxy de almacenamiento en caché de código abierto para la Web que admite HTTP, HTTPS, FTP y más. Debido a un error de colapso de datos en valor inseguro, Squid puede ser vulnerable a un ataque de denegación de servicio contra el análisis de encabezados HTTP. Este problema permite que un cliente remoto o un servidor remoto realice una Denegación de Servicio al enviar encabezados de gran tamaño en mensajes HTTP. En versiones de Squid anteriores a la 6.5, esto se puede lograr si las configuraciones request_header_max_size o Reply_header_max_size no se modifican con respecto a las predeterminadas. En la versión 6.5 y posteriores de Squid, la configuración predeterminada de estos parámetros es segura. Squid emitirá una advertencia crítica en cache.log si el administrador configura estos parámetros en valores no seguros. Squid no impedirá en este momento que estas configuraciones se cambien a valores inseguros. Se recomienda a los usuarios que actualicen a la versión 6.5. No se conocen workarounds para esta vulnerabilidad. Este problema también se rastrea como SQUID-2024:2

Mastodon es un servidor de red social gratuito y de código abierto basado en ActivityPub. Mastodon permite que nuevas identidades de proveedores de autenticación configurados (CAS, SAML, OIDC) se adjunten a usuarios locales existentes con la misma dirección de correo electrónico. Esto da como resultado una posible apropiación de la cuenta si el proveedor de autenticación permite cambiar la dirección de correo electrónico o si se configuran varios proveedores de autenticación. Cuando un usuario inicia sesión a través de un proveedor de autenticación externo por primera vez, Mastodon verifica la dirección de correo electrónico transmitida por el proveedor para encontrar una cuenta existente. Sin embargo, usar solo la dirección de correo electrónico significa que si el proveedor de autenticación permite cambiar la dirección de correo electrónico de una cuenta, la cuenta de Mastodon puede ser secuestrada inmediatamente. Todos los usuarios que inician sesión a través de proveedores de autenticación externos se ven afectados. La gravedad es media, ya que también requiere que el proveedor de autenticación externo se comporte mal. Sin embargo, algunos proveedores de OIDC conocidos (como Microsoft Azure) hacen que sea muy fácil permitir accidentalmente cambios de correo electrónico no verificados. Además, OpenID Connect también permite el registro dinámico de clientes. Este problema se solucionó en las versiones 4.2.6, 4.1.14, 4.0.14 y 3.5.18. Se recomienda a los usuarios que actualicen. No se conocen workarounds para esta vulnerabilidad.

Mastodon es un servidor de red social gratuito y de código abierto basado en ActivityPub. Cuando se destruye una aplicación OAuth, no se informaba al servidor de transmisión que los tokens de acceso también se habían destruido, lo que podría haber planteado riesgos de seguridad para los usuarios al permitir que una aplicación continuara escuchando la transmisión después de que la aplicación hubiera sido destruida. Esencialmente, esto se reduce al hecho de que cuando Doorkeeper configura la relación entre las aplicaciones y los tokens de acceso, utiliza una configuración `dependent: delete_all`, lo que significa que la configuración de devolución de llamada `after_commit` en `AccessTokenExtension` en realidad no se activó, ya que ` delete_all` no activa devoluciones de llamada de ActiveRecord. Para mitigar, necesitamos agregar una devolución de llamada `before_destroy` a `ApplicationExtension` que anuncia a la transmisión que todos los tokens de acceso de la aplicación están siendo "eliminados". El impacto debería ser insignificante dado que la aplicación afectada tenía que ser propiedad del usuario. No obstante, este problema se ha solucionado en las versiones 4.2.6, 4.1.14, 4.0.14 y 3.5.18. Se recomienda a los usuarios que actualicen. No se conocen workaround para esta vulnerabilidad.