Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sched: taprio: validar siempre TCA_TAPRIO_ATTR_PRIOMAP Si se ha proporcionado un atributo TCA_TAPRIO_ATTR_PRIOMAP, taprio_parse_mqprio_opt() debe validarlo, o el espacio de usuario puede inyectar datos arbitrarios al kernel, la segunda vez taprio_change () se llama. La primera llamada (con atributos válidos) establece dev->num_tc en un valor distinto de cero. La segunda llamada (con atributos mqprio arbitrarios) regresa temprano desde taprio_parse_mqprio_opt() y pueden suceder cosas malas.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: usb: dwc3: Espere incondicionalmente después de emitir el comando EndXfer Actualmente, todas las IP/revisiones del controlador excepto DWC3_usb3 >= 310a esperan 1 ms incondicionalmente para que ENDXFER se complete cuando el IOC no está configurado. Esto se debe a que las revisiones del controlador DWC_usb3 >= 3.10a admiten el bit GUCTL2[14: Rst_actbitlater] que permite sondear el bit CMDACT para saber si se completó el comando ENDXFER. Considere un caso en el que se puso en cola una solicitud IN y, en paralelo, se llamó a soft_disconnect (debido a ffs_epfile_release). Esto eventualmente llama a stop_active_transfer con el IOC borrado, por lo tanto, send_gadget_ep_cmd() omite la espera de que CMDACT se borre durante EndXfer. Para los controladores DWC3 con revisiones >= 310a, tampoco esperamos forzosamente 1 ms y procedemos a desasignar las solicitudes. Si ENDXFER no se completó en este momento, se producirán fallas de SMMU ya que el controlador aún estaría accediendo a esas solicitudes. Solucione este problema asegurando la finalización de ENDXFER agregando un retraso de 1 ms en __dwc3_stop_active_transfer() incondicionalmente.

Se descubrió que DuxCMS3 v3.1.3 contenía una vulnerabilidad de inyección SQL a través del parámetro de palabra clave en /article/Content/index?class_id.

CORSAIR iCUE 5.9.105 con iCUE Murals en Windows permite a usuarios sin privilegios insertar archivos DLL en el subdirectorio cuepkg-1.2.6 del directorio de instalación.

Una posible debilidad en las funciones de protección AMD SPI puede permitir que un atacante malicioso con acceso Ring0 (modo kernel) evite las protecciones ROM nativas del modo de administración del sistema (SMM).

Se descubrió que CodeProjects Restaurant Reservation System v1.0 contiene una vulnerabilidad de cross-site scripting (XSS) reflejado a través del parámetro Fecha en index.php.

Se descubrió que CodeProjects Health Care hospital Management System v1.0 contenía una vulnerabilidad de inyección SQL en el módulo de información del paciente a través del parámetro servalu.

Múltiples vulnerabilidades de cross-site scripting (XSS) almacenado en CodeProjects Health Care hospital Management System v1.0 permiten a los atacantes ejecutar scripts web o HTML arbitrarios a través de un payload manipulado inyectado en los parámetros fname y lname en la página de información del personal.

Minder es una plataforma de seguridad de la cadena de suministro de software de código abierto. El proveedor Git de Minder es vulnerable a una denegación de servicio desde un repositorio GitHub configurado maliciosamente. El proveedor de Git clona los repositorios de los usuarios utilizando la librería `github.com/go-git/go-git/v5` en las líneas `L55-L89`. El proveedor de Git hace lo siguiente en las líneas "L56-L62". Primero, establece `CloneOptions`, especificando la URL, la profundidad, etc. Luego valida las opciones. Luego configura un sistema de archivos en memoria, al cual clona y, finalmente, clona el repositorio. El método `(g *Git) Clone()` es vulnerable a un ataque DoS: un usuario de Minder puede indicarle a Minder que clone un repositorio grande que agotará la memoria y bloqueará el servidor de Minder. La causa principal de esta vulnerabilidad es una combinación de las siguientes condiciones: 1. Los usuarios pueden controlar la URL de Git que Minder clona, 2. Minder no impone un límite de tamaño al repositorio, 3. Minder clona todo el repositorio en la memoria. Este problema se solucionó en el commit `7979b43` que se incluyó en la versión v0.0.52. Se recomienda a los usuarios que actualicen. No se conocen workarounds para esta vulnerabilidad.

Se descubrió que CodeProjects Health Care hospital Management System v1.0 contenía una vulnerabilidad de inyección SQL en el módulo de información de la habitación a través del parámetro id.

Se descubrió que CodeProjects Health Care hospital Management System v1.0 contenía una vulnerabilidad de inyección SQL en el módulo de información del personal a través del parámetro servalu.

Pocketbase es un backend web de código abierto escrito en go. En las versiones afectadas, un usuario malintencionado puede comprometer las cuentas de otros usuarios. Para ser explotados, los usuarios deben tener habilitados los métodos de autenticación OAuth2 y Contraseña. Un posible escenario de ataque podría ser: 1. un actor malintencionado se registra con el correo electrónico del usuario objetivo (no está verificado), 2. en algún momento posterior, el usuario objetivo tropieza con su aplicación y decide registrarse con OAuth2 (_este paso El atacante también podría iniciarlo enviando un correo electrónico de invitación al usuario objetivo_), 3. en una autenticación OAuth2 exitosa, buscamos un usuario de PocketBase existente que coincida con el correo electrónico del usuario OAuth2 y lo asociamos, 4. porque no hemos cambiado el contraseña del usuario de PocketBase existente durante la vinculación, el actor malicioso tiene acceso a la cuenta de usuario objetivo y podrá iniciar sesión con el correo electrónico/contraseña creado inicialmente. Para evitar que esto suceda, ahora restablecemos la contraseña para este caso específico si el usuario creado anteriormente no fue verificado (una excepción a esto es si el enlace es explícito/manual, también conocido como cuando envía `Autorización:TOKEN` con OAuth2 llamada de autenticación). Además, para advertir a los usuarios existentes, ahora enviamos una alerta por correo electrónico en caso de que el usuario haya iniciado sesión con contraseña pero tenga al menos una cuenta OAuth2 vinculada. El flujo se mejorará aún más con la refactorización continua y comenzaremos a enviar correos electrónicos para inicios de sesión de "dispositivos no reconocidos" (OTP y MFA ya están implementados y estarán disponibles con la próxima versión v0.23.0 en un futuro próximo). Por el momento, se recomienda a los usuarios que actualicen a la versión 0.22.14. No se conocen workarounds para esta vulnerabilidad.