Vulnerabilidades

Versión 3.0.7 de la Extensión Securly Chrome utiliza derivación de clave EVP_BytesToKey con MD5 y una sola iteración para el cifrado AES. MD5 ha sido roto desde 2004 y una sola iteración no proporciona estiramiento de clave.

La versión 3.0.7 de la Securly Chrome Extension descarga config.json sobre HTTP y compila patrones proporcionados por el servidor como expresiones regulares de JavaScript a través de new RegExp() sin validación de complejidad. Un atacante en la ruta puede inyectar patrones específicos para causar un retroceso catastrófico, resultando en denegación de servicio en toda la navegación.

La Versión 3.0.7 de la Extensión de Chrome de Securly utiliza hash SHA-1 obsoleto para la coincidencia de URL CSAM de IWF (25.020 hashes) y la coincidencia de lista de bloqueo CIPA (12.352 hashes).

Un usuario autenticado de ERPNext con permisos de edición de registros de Artículo puede persistir HTML/JavaScript arbitrario en los campos item_name, description o image de un Artículo y desencadenar una renderización sin escape en la interfaz del carrito del Punto de Venta (TPV) para cada operador que añade ese artículo a una transacción. Este problema afecta a ERPNext: 16.16.0.

Un usuario autenticado puede persistir HTML/JavaScript arbitrario en los campos email_id o mobile_no de un registro de Cliente y desencadenar una renderización sin escape en la interfaz del Punto de Venta (POS) para cada operador que seleccione a ese cliente.<br /> Este problema afecta a ERPNext: 16.16.0.

OP-TEE es un Entorno de Ejecución Confiable (TEE) diseñado como compañero de un kernel de Linux no seguro ejecutándose en núcleos Arm; Cortex-A usando la tecnología TrustZone. Antes de la versión 4.11.0, en muchas de las rutas de secreto compartido ECDH, la clave pública no se verifica para ser un punto en la curva correcta. Al pasar aproximadamente 30-40 claves públicas manipuladas a OP-TEE, la clave privada puede ser reconstruida por un atacante del mundo normal. Al llamar a TEE_DeriveKey, la clave pública se proporciona con valores X e Y completos, pero el punto (X, Y) podría no satisfacer las matemáticas &amp;#39;Y^2 == X^3 + aX + b mod P&amp;#39; para la curva específica que se utiliza. Cuando esas claves públicas no son rechazadas, el atacante puede seleccionar claves públicas de tal manera que cada llamada a DeriveKey filtrará &amp;#39;d % r&amp;#39; donde &amp;#39;d&amp;#39; es la clave privada y &amp;#39;r&amp;#39; proviene de la relación entre la curva correcta y la curva seleccionada por el atacante. Con suficientes datos filtrados, el teorema chino del resto puede usarse para recuperar la clave privada completa. La versión 4.11.0 corrige el problema.

OP-TEE es un Entorno de Ejecución Confiable (TEE) diseñado como compañero de un kernel de Linux no seguro ejecutándose en núcleos Arm; Cortex-A utilizando la tecnología TrustZone. A partir de la versión 4.3.0 y antes de la versión 4.11.0, existe una vulnerabilidad de confusión de tipos en OP-TEE OS al procesar una solicitud FFA_MEM_SHARE desde el mundo normal. Esto solo aplica cuando OP-TEE está configurado como un SPMC para SPs S-EL0, es decir, con &amp;#39;CFG_CORE_SEL1_SPMC=y&amp;#39; y &amp;#39;CFG_SECURE_PARTITION=y&amp;#39;. La versión 4.11.0 corrige el problema.

Concrete CMS anterior a 9.5.2 es vulnerable a la Inyección de objetos PHP a través de llamadas a unserialize() en los componentes Workflow, Form block y File/Set que carecen de la restricción allowed_classes. Un atacante no autenticado puede desencadenar la instanciación arbitraria de objetos PHP si se ha colocado una carga útil serializada maliciosa en la base de datos. Gracias a XananasX7 y Sanjorn Keeratirungsan (dizconnect) por informar ambos de forma independiente. El equipo de seguridad de Concrete CMS otorgó a esta vulnerabilidad una puntuación CVSS v.4.0 de 8.4 con el vector CVSS:4.0/AV:L/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N.

Vulnerabilidad de Cross Site Scripting en Koha 25.11 y versiones anteriores permite a un atacante remoto ejecutar código arbitrario a través de la función de carga de archivos en las características de Facturación.

Un problema en Koha v.25.11 y anteriores permite a un atacante remoto ejecutar código arbitrario a través del módulo de configuración Z39.50.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> coresight: tmc-etr: Soluciona condición de carrera entre el modo sysfs y perf<br /> <br /> Al intentar ejecutar los modos perf y sysfs simultáneamente, el WARN_ON() en tmc_etr_enable_hw() se activa a veces:<br /> <br /> ADVERTENCIA: CPU: 42 PID: 3911571 en drivers/hwtracing/coresight/coresight-tmc-etr.c:1060 tmc_etr_enable_hw+0xc0/0xd8 [coresight_tmc]<br /> [..recorte..]<br /> Rastro de llamada:<br /> tmc_etr_enable_hw+0xc0/0xd8 [coresight_tmc] (P)<br /> tmc_enable_etr_sink+0x11c/0x250 [coresight_tmc] (L)<br /> tmc_enable_etr_sink+0x11c/0x250 [coresight_tmc]<br /> coresight_enable_path+0x1c8/0x218 [coresight]<br /> coresight_enable_sysfs+0xa4/0x228 [coresight]<br /> enable_source_store+0x58/0xa8 [coresight]<br /> dev_attr_store+0x20/0x40<br /> sysfs_kf_write+0x4c/0x68<br /> kernfs_fop_write_iter+0x120/0x1b8<br /> vfs_write+0x2c8/0x388<br /> ksys_write+0x74/0x108<br /> __arm64_sys_write+0x24/0x38<br /> el0_svc_common.constprop.0+0x64/0x148<br /> do_el0_svc+0x24/0x38<br /> el0_svc+0x3c/0x130<br /> el0t_64_sync_handler+0xc8/0xd0<br /> el0t_64_sync+0x1ac/0x1b0<br /> ---[ fin del rastro 0000000000000000 ]---<br /> <br /> Dado que la habilitación del modo sysfs está separada en dos regiones críticas, una para la asignación del búfer sysfs y otra para la habilitación del hardware, es posible que haya una condición de carrera con el modo perf. Soluciona esto verificando dos veces si el modo perf ha sido utilizado antes de habilitar el hardware en el modo sysfs.<br /> <br /> modo:<br /> [modo sysfs] [modo perf]<br /> tmc_etr_get_sysfs_buffer()<br /> spin_lock(&amp;drvdata-&gt;spinlock)<br /> [asignación de búfer sysfs]<br /> spin_unlock(&amp;drvdata-&gt;spinlock)<br /> spin_lock(&amp;drvdata-&gt;spinlock)<br /> tmc_etr_enable_hw()<br /> drvdata-&gt;etr_buf = etr_perf-&gt;etr_buf<br /> spin_unlock(&amp;drvdata-&gt;spinlock)<br /> spin_lock(&amp;drvdata-&gt;spinlock)<br /> tmc_etr_enable_hw()<br /> WARN_ON(drvdata-&gt;etr_buf) // ADVERTENCIA ya que etr_buf inicializado en<br /> el lado perf<br /> spin_unlock(&amp;drvdata-&gt;spinlock)<br /> <br /> Con esta solución, mantenemos la verificación de CS_MODE_PERF en get_etr_sysfs_buf. Esto asegura que verifiquemos si el modo perf ya está en ejecución antes de asignar realmente el búfer. Entonces podemos ahorrar el tiempo de asignar/liberar el búfer sysfs si hay una condición de carrera con el modo perf.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ibmveth: Deshabilitar GSO para paquetes con MSS pequeño<br /> <br /> Algunos adaptadores físicos en sistemas Power no soportan la descarga de segmentación cuando el MSS es inferior a 224 bytes. Intentar enviar dichos paquetes hace que el adaptador se congele, deteniendo todo el tráfico hasta que se reinicie manualmente.<br /> <br /> Implementar ndo_features_check para deshabilitar GSO para paquetes con valores de MSS pequeños. La pila de red realizará la segmentación por software en su lugar.<br /> <br /> El mínimo de 224 bytes coincide con el commit de ibmvnic (&amp;#39;ibmvnic: Aplicar comprobaciones de cordura más estrictas en los paquetes GSO&amp;#39;) que utiliza los mismos adaptadores físicos en configuraciones SEA.<br /> <br /> El problema ocurre específicamente cuando el hardware intenta realizar la segmentación (gso_segs &gt; 1) con un MSS pequeño. Los paquetes GSO de un solo segmento (gso_segs == 1) no activan la ruta de código LSO problemática y se transmiten normalmente sin segmentación.<br /> <br /> Añadir una devolución de llamada ndo_features_check para deshabilitar GSO cuando MSS