Vulnerabilidades

El servicio de clúster de CloudStack se ejecuta en un puerto no autenticado (9090 predeterminado) que puede usarse indebidamente para ejecutar comandos arbitrarios en hipervisores específicos y hosts de servidores de administración de CloudStack. Se descubrió que algunos de estos comandos tenían vulnerabilidades de inyección de comandos que pueden resultar en la ejecución de código arbitrario a través de agentes en los hosts que pueden ejecutarse como un usuario privilegiado. Un atacante que pueda acceder al servicio de clúster en el puerto no autenticado (9090 predeterminado) puede aprovechar esto para realizar la ejecución remota de código en hosts administrados por CloudStack y comprometer completamente la confidencialidad, integridad y disponibilidad de la infraestructura administrada por CloudStack. Se recomienda a los usuarios restringir el acceso a la red al puerto de servicio de clúster (9090 predeterminado) en un host del servidor de administración de CloudStack solo a sus hosts del servidor de administración de CloudStack pares. Se recomienda a los usuarios actualizar a la versión 4.18.2.1, 4.19.0.2 o posterior, que soluciona este problema.

** NO SOPORTADO CUANDO SE ASIGNÓ ** Se encontró una vulnerabilidad en D-Link DAR-7000 hasta 20230922. Se calificó como problemática. Una función desconocida del archivo /log/decodmail.php es afectada por esta vulnerabilidad. La manipulación del argumento file conduce a la deserialización. El ataque puede lanzarse de forma remota. El exploit ha sido divulgado al público y puede utilizarse. El identificador de esta vulnerabilidad es VDB-270368. NOTA: Esta vulnerabilidad solo afecta a productos que ya no son compatibles con el mantenedor.

Se encontró una vulnerabilidad en ShopXO hasta 6.1.0. Ha sido declarada crítica. Una función desconocida del archivo extend/base/Uploader.php es afectada por esta vulnerabilidad. La manipulación del argumento source conduce a server-side request forgery. El ataque se puede lanzar de forma remota. El exploit ha sido divulgado al público y puede utilizarse. El identificador asociado de esta vulnerabilidad es VDB-270367. NOTA: La divulgación original confunde CSRF con SSRF.

Acceso no autorizado a archivos en WEB Server en ABB ASPECT - Enterprise v <=3.08.01; Serie NEXUS v <=3.08.01; MATRIX Series v<=3.08.01 permite a un atacante acceder a archivos no autorizados

Vulnerabilidad de validación de entrada incorrecta en ABB ASPECT-Enterprise en Linux, ABB NEXUS Series en Linux, ABB MATRIX Series en Linux permite la inclusión remota de código. Este problema afecta a ASPECT-Enterprise: hasta 3.08.01; Serie NEXUS: hasta el 3.08.01; Serie MATRIX: hasta el 3.08.01.

Se encontró una vulnerabilidad en ZKTeco BioTime hasta 9.5.2. Ha sido clasificada como problemática. Una función desconocida del componente system-group-add Handler es afectada por esta vulnerabilidad. La manipulación del argumento usuario con la entrada conduce a cross site scripting. Es posible lanzar el ataque de forma remota. El exploit ha sido divulgado al público y puede utilizarse. VDB-270366 es el identificador asignado a esta vulnerabilidad. NOTA: Se contactó primeramente con el proveedor sobre esta divulgación, pero no respondió de ninguna manera.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ASoC: SOF: ipc4-topology: arregla la consulta de formato de entrada de módulos de proceso sin extensión base. Si un módulo de proceso no tiene extensión de configuración base, entonces se aplica el mismo formato a todas sus entradas. y el proceso->base_config_ext es NULL, lo que provoca una desreferencia NULL cuando se utilizan secuencias y topologías manipuladas específicamente.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fbdev: savage: Maneja el retorno de error cuando falla savagefb_check_var. El commit 04e5eac8f3ab("fbdev: savage: Error out if pixclock es igual a cero") verifica el valor de pixclock para evitar división por error cero. Sin embargo, la función savagefb_probe no maneja la devolución de error de savagefb_check_var. Cuando pixclock es 0, provocará un error de división por cero.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: md/raid5: corrige el punto muerto que raid5d() espera a que se borre MD_SB_CHANGE_PENDING Xiao informó que la prueba lvm2 lvconvert-raid-takeover.sh puede bloquearse con una pequeña posibilidad, la causa principal es exactamente lo mismo que el commit bed9e27baf52 ("Revertir "md/raid5: Espere MD_SB_CHANGE_PENDING en raid5d") Sin embargo, Dan informó otro bloqueo después de eso, y Junxiao investigó el problema y descubrió que esto se debe a que la biografía conectada no puede emitir de raid5d(). La implementación actual en raid5d() tiene una dependencia extraña: 1) md_check_recovery() de raid5d() debe mantener 'reconfig_mutex' para borrar MD_SB_CHANGE_PENDING; 2) raid5d() maneja IO en un bucle muerto, hasta que se emiten todas las IO; 3) IO de raid5d() debe esperar a que se borre MD_SB_CHANGE_PENDING; Este comportamiento se introdujo antes de v2.6 y, como consecuencia, si otro contexto contiene 'reconfig_mutex' y md_check_recovery() no puede actualizar super_block, entonces raid5d() desperdiciará una CPU al 100% mediante el bucle muerto, hasta que 'reconfig_mutex' sea liberado. Consulte la implementación de raid1 y raid10, solucione este problema omitiendo el problema IO si MD_SB_CHANGE_PENDING todavía está configurado después de md_check_recovery(), el hilo del daemon se activará cuando se publique 'reconfig_mutex'. Mientras tanto, el problema de bloqueo también se solucionará.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mm/hugetlb: no llame a vma_add_reservation cuando ENOMEM sysbot informó un splat [1] en __unmap_hugepage_range(). Esto se debe a que vma_needs_reservation() puede devolver -ENOMEM si allocate_file_region_entries() no puede asignar la estructura file_region para la reserva. Verifique eso y no llame a vma_add_reservation() si ese es el caso; de lo contrario, region_abort() y region_del() verán que no tenemos ningún file_regions. Si detectamos que vma_needs_reservation() devolvió -ENOMEM, borramos el indicador hugetlb_restore_reserve como si esta reserva todavía estuviera consumida, por lo que free_huge_folio() no incrementará el recuento de resv. [1] https://lore.kernel.org/linux-mm/0000000000004096100617c58d54@google.com/T/#ma5983bc1ab18a54910da83416b3f89f3c7ee43aa

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: crypto: starfive: no liberar el búfer de pila Los datos de texto RSA utilizan un búfer de longitud variable asignado en la pila de software. Llamar a kfree provoca un comportamiento indefinido en operaciones posteriores.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/i915/hwmon: deshacerse de devm Cuando tanto hwmon como hwmon drvdata (del cual depende hwmon) son recursos administrados por el dispositivo, la expectativa, al desvincular el dispositivo, es que hwmon publicarse antes que drvdata. Sin embargo, en i915 hay dos rutas de código independientes, que liberan drvdata o hwmon y cualquiera de ellas puede publicarse antes que la otra. Estas rutas de código (para desvincular el dispositivo) son las siguientes (consulte también el error al que se hace referencia a continuación): Seguimiento de llamadas: release_nodes+0x11/0x70 devres_release_group+0xb2/0x110 componente_unbind_all+0x8d/0xa0 componente_del+0xa5/0x140 intel_pxp_tee_component_fini+0x29/0x40 [i915 ] intel_pxp_fini+0x33/0x80 [i915] i915_driver_remove+0x4c/0x120 [i915] i915_pci_remove+0x19/0x30 [i915] pci_device_remove+0x32/0xa0 dispositivo_release_driver_internal+0x19c/0x200 store+0x9c/0xb0 y seguimiento de llamadas: release_nodes+0x11/0x70 devres_release_all +0x8a/0xc0 device_unbind_cleanup+0x9/0x70 device_release_driver_internal+0x1c1/0x200 unbind_store+0x9c/0xb0 Esto significa que en i915, si usa devm, no podemos garantizar que hwmon siempre se publicará antes que drvdata. Lo que significa que tenemos un uaf si se accede a hwmon sysfs cuando drvdata se lanzó pero hwmon no. La única forma de solucionar esto parece ser deshacerse de devm_ y liberar/liberar todo explícitamente durante la desvinculación del dispositivo. v2: Cambiar mensaje de confirmación y otros cambios menores de código v3: Limpieza de i915_hwmon_register en caso de error (Armin Wolf) v4: Eliminar posible advertencia del analizador estático (Rodrigo) Eliminar fetch_and_zero (Jani) v5: Restaurar la lógica anterior para el retorno de error ddat_gt->hwmon_dev (Andi )