Vulnerabilidades

En Brocade SANnav, antes de Brocade SANnav v2.3.0, el tráfico de syslog recibía texto plano. Esto podría permitir que un atacante remoto no autenticado capture información confidencial.

Brocade SANnav anterior a Brocade SANnav v2.3.1 carece de mecanismos de protección en los puertos 2377/TCP y 7946/TCP, lo que podría permitir que un atacante remoto no autenticado acceda a las API de Kafka y envíe datos maliciosos.

El complemento AGCA WordPress anterior a 7.2.2 no sanitiza ni escapa a algunas de sus configuraciones, lo que podría permitir a usuarios con privilegios elevados, como el administrador, realizar ataques de Cross-Site Scripting Almacenado incluso cuando la capacidad unfiltered_html no está permitida (por ejemplo, en una configuración multisitio).

Una vulnerabilidad de verificación inadecuada de condiciones inusuales o excepcionales en el componente web de Ivanti Connect Secure (9.x, 22.x) e Ivanti Policy Secure (9.x, 22.x) permite a un atacante remoto no autenticado enviar solicitudes especialmente manipuladas en -orden-para causar interrupciones en el servicio.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nft_set_pipapo: no liberar elemento activo Pablo informa un bloqueo con grandes lotes de elementos con un patrón de agregar/eliminar consecutivos. Citando a Pablo: add_elem("00000000") timeout 100 ms ... add_elem("0000000X") timeout 100 ms del_elem("0000000X") <---------------- elimina uno que se acaba de agregar... add_elem("00005000") tiempo de espera 100 ms 1) nft_pipapo_remove() elimina el elemento 0000000X Luego, KASAN muestra un símbolo. Al observar la función de eliminación, existe la posibilidad de que eliminemos una regla que se asigne a un elemento no desactivado. La eliminación se realiza en dos pasos: primero buscamos la clave k, devolvemos el elemento que se va a eliminar y lo marcamos como inactivo en la próxima generación. Luego, en un segundo paso, el elemento se elimina del conjunto/mapa. La función _remove no funciona correctamente si tenemos más de un elemento que comparte la misma clave. Esto puede suceder si insertamos un elemento en un conjunto cuando el conjunto ya contiene un elemento con la misma clave, pero la asignación del elemento a la clave existente ha expirado o no está activa en la próxima generación. En tal caso, es posible que la eliminación desasigne el elemento incorrecto. Si esto sucede, filtraremos el elemento no desactivado, se vuelve inalcanzable. El elemento que se desactivó (y se liberará más adelante) permanecerá accesible en la estructura de datos establecida, lo que puede provocar un bloqueo cuando dicho elemento se recupere durante la búsqueda (puntero obsoleto). Agregue una verificación de que la clave que coincide completamente de hecho se asigna al elemento que hemos marcado como inactivo en el paso de desactivación. Si no, debemos seguir buscando. Agregue también una trampa de error/advertencia al final de la función; la función de eliminación nunca debe llamarse con un elemento invisible/inalcanzable/inexistente. v2: evitar variables temporales innecesarias (Stefano)

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Binder: verifique la alineación de desplazamiento en binder_get_object() El commit 6d98eb95b450 ("binder: evite posibles fugas de datos al copiar txn") introdujo cambios en la forma en que se copian los objetos de Binder. Al hacerlo, eliminó involuntariamente una verificación de alineación de desplazamiento realizada mediante llamadas a binder_alloc_copy_from_buffer() -> check_buffer(). Estas llamadas fueron reemplazadas en binder_get_object() con copy_from_user(), por lo que ahora se necesita aquí una verificación explícita de alineación de desplazamiento. Esto evita complicaciones posteriores cuando el desenrollado de los objetos se vuelve más difícil. Vale la pena señalar que esta verificación existía antes de el commit 7a67a39320df ("carpeta: agregar función para copiar el objeto de carpeta del búfer"), probablemente eliminada debido a la redundancia en ese momento.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: af_unix: corrige la ejecución del recolector de basura contra connect() El recolector de basura no tiene en cuenta el riesgo de que el embrión quede en cola durante la recolección de basura. Si dicho embrión tiene un par que porta SCM_RIGHTS, dos pases consecutivos de scan_children() pueden ver un conjunto diferente de niños. Lo que lleva a un recuento en vuelo elevado incorrectamente y luego a un puntero colgante dentro de gc_inflight_list. los sockets son AF_UNIX/SOCK_STREAM S es un socket no conectado L es un socket de escucha en vuelo vinculado a addr, no en fdtable El fd de V se pasará a través de sendmsg(), se aumenta el recuento en vuelo connect(S, addr) sendmsg(S, [ V]); cerrar(V) __unix_gc() ---------- ------------------------- -- --------- NS = unix_create1() skb1 = sock_wmalloc(NS) L = unix_find_other(addr) unix_state_lock(L) unix_peer(S) = NS // V count=1 en vuelo=0 NS = unix_peer(S ) skb2 = sock_alloc() skb_queue_tail(NS, skb2[V]) // V se convirtió en vuelo // V recuento=2 en vuelo=1 close(V) // V recuento=1 en vuelo=1 // Condición candidata de GC cumplida para u en gc_inflight_list: if (total_refs == inflight_refs) agregue u a gc_candidates // gc_candidates={L, V} para u en gc_candidates: scan_children(u, dec_inflight) // el embrión (skb1) aún no era // accesible desde L , por lo que V's // en vuelo permanece sin cambios __skb_queue_tail(L, skb1) unix_state_unlock(L) para u en gc_candidates: if (u.inflight) scan_children(u, inc_inflight_move_tail) // V count=1 inflight=2 (!) Si hay un socket de escucha candidato a GC, bloquear/desbloquear su estado. Esto hace que GC espere hasta el final de cualquier conexión () en curso a ese socket. Después de girar la cerradura, un embrión posiblemente cargado de SCM ya está en cola. Y si viene otro embrión, no es posible que porte SCM_RIGHTS. En este punto, unix_inflight() no puede ocurrir porque unix_gc_lock ya está en uso. El gráfico a bordo no se ve afectado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nf_tables: libera mutex después de nft_gc_seq_end de la ruta de cancelación. El mutex de confirmación no debe liberarse durante la sección crítica entre nft_gc_seq_begin() y nft_gc_seq_end(); de lo contrario, el trabajador asíncrono de GC podría recopilar objetos caducados y obtener el bloqueo de confirmación liberado dentro de la misma secuencia de GC. nf_tables_module_autoload() libera temporalmente el mutex para cargar las dependencias del módulo, luego vuelve a reproducir la transacción nuevamente. Muévalo al final de la fase de cancelación después de llamar a nft_gc_seq_end().

Una vulnerabilidad de lectura fuera de los límites en el componente WLAvalancheService de Ivanti Avalanche anterior a 6.4.3, en ciertas condiciones, puede permitir que un atacante remoto no autenticado lea información confidencial en la memoria.

Una vulnerabilidad en la interfaz de administración basada en web del software Cisco TelePresence Management Suite (TMS) podría permitir que un atacante remoto autenticado lleve a cabo un ataque de cross-site scripting (XSS) contra un usuario de la interfaz. Esta vulnerabilidad se debe a una validación de entrada insuficiente por parte de la interfaz de administración basada en web. Un atacante podría aprovechar esta vulnerabilidad insertando datos maliciosos en un campo de datos específico de la interfaz. Un exploit exitoso podría permitir al atacante ejecutar código de script arbitrario en el contexto de la interfaz afectada o acceder a información confidencial basada en el navegador.

Una vulnerabilidad en la interfaz de administración basada en web del software Cisco TelePresence Management Suite (TMS) podría permitir que un atacante remoto autenticado lleve a cabo un ataque de cross-site scripting (XSS) contra un usuario de la interfaz. Esta vulnerabilidad se debe a una validación de entrada insuficiente por parte de la interfaz de administración basada en web. Un atacante podría aprovechar esta vulnerabilidad insertando datos maliciosos en un campo de datos específico de la interfaz. Un exploit exitoso podría permitir al atacante ejecutar código de script arbitrario en el contexto de la interfaz afectada o acceder a información confidencial basada en el navegador.

Una vulnerabilidad en la característica OSPF versión 2 (OSPFv2) del software Cisco IOS XE podría permitir que un atacante adyacente no autenticado provoque que un dispositivo afectado se recargue inesperadamente, lo que resultaría en una condición de denegación de servicio (DoS). Esta vulnerabilidad se debe a una validación inadecuada de las actualizaciones OSPF procesadas por un dispositivo. Un atacante podría aprovechar esta vulnerabilidad enviando una actualización OSPF con formato incorrecto al dispositivo. Un exploit exitoso podría permitir al atacante hacer que el dispositivo afectado se recargue, lo que resultaría en una condición DoS.