Vulnerabilidades

El complemento Flamix: Bitrix24 and Contact Form 7 integrations para WordPress es vulnerable a la divulgación de ruta completa en todas las versiones hasta la 3.1.0 incluida. Esto se debe al complemento que utiliza mobiledetect sin impedir el acceso directo a los archivos. Esto hace posible que atacantes no autenticados recuperen la ruta completa de la aplicación web, que puede usarse para ayudar en otros ataques. La información mostrada no es útil por sí sola y requiere que esté presente otra vulnerabilidad para dañar un sitio web afectado.

El complemento WordSurvey para WordPress es vulnerable a Cross-Site Scripting Almacenado a través del parámetro 'sounding_title' en todas las versiones hasta la 3.2 incluida debido a una desinfección de entrada y un escape de salida insuficientes. Esto hace posible que atacantes autenticados, con acceso a nivel de administrador, inyecten scripts web arbitrarios en páginas que se ejecutarán cada vez que un usuario acceda a una página inyectada. Esto solo afecta a las instalaciones multisitio y a las instalaciones en las que se ha deshabilitado unfiltered_html.

El complemento Hide My Site para WordPress es vulnerable a la exposición de información confidencial en todas las versiones hasta la 2.2 incluida debido a que el complemento no restringe el acceso a la API REST cuando la protección con contraseña está habilitada. Esto hace posible que atacantes no autenticados obtengan acceso no autorizado al sitio.

Una vulnerabilidad de cross-site scripting (XSS) en el componente /index/index.html de YZNCMS v1.4.2 permite a los atacantes ejecutar scripts web o HTML arbitrario a través de un payload manipulado inyectado en el campo de texto de comentarios configurado.

Dell SupportAssist for Home PCs Installer exe versión 4.0.3 contiene una vulnerabilidad de escalada de privilegios en el instalador. Un atacante local autenticado con pocos privilegios podría explotar esta vulnerabilidad, lo que llevaría a la ejecución de ejecutables arbitrarios en el sistema operativo con privilegios elevados.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: medios: pci: ivtv: Agregar verificación para el resultado del mapa DMA En caso de que DMA falle, 'dma->SG_length' es 0. Este valor se usa luego para acceder a 'dma->SGarray [dma->SG_length - 1]', lo que provocará un acceso fuera de los límites. Agregue un cheque para devolver anticipadamente un valor no válido. Ajuste las advertencias en consecuencia. Encontrado por el Centro de verificación de Linux (linuxtesting.org) con SVACE.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xfrm: corrige el error de acceso a la memoria de la ruta de entrada Cuando hay una mala configuración del estado de entrada, la ruta lenta KASAN informa el error. Corrija este error. inicio de sesión oeste: [52.987278] eth1: renombrado de veth11 [53.078814] eth1: renombrado de veth21 [53.181355] eth1: renombrado de veth31 [54.921702] ===================== =============================================== [ 54.922602] ERROR : KASAN: acceso a memoria salvaje en xfrmi_rcv_cb+0x2d/0x295 [ 54.923393] Lectura de tamaño 8 en la dirección 6b6b6b6b00000000 mediante tarea ping/512 [ 54.924169] [ 54.924386] CPU: 0 PID: 512 Comm: ping No contaminado 6. 9.0- 08574-gcd29a4313a1b #25 [ 54.925290] Nombre de hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 01/04/2014 [ 54.926401] Seguimiento de llamadas: [ 54.926731] [54.927009] dump_stack_lvl+0x2a/0x3b [54.927478] kasan_report+0x84/0xa6 [54.927930]? xfrmi_rcv_cb+0x2d/0x295 [ 54.928410] xfrmi_rcv_cb+0x2d/0x295 [ 54.928872] ? xfrm4_rcv_cb+0x3d/0x5e [ 54.929354] xfrm4_rcv_cb+0x46/0x5e [ 54.929804] xfrm_rcv_cb+0x7e/0xa1 [ 54.930240] xfrm_input+0x1b3a/0x1b96 [ 54.930715] ? xfrm_offload+0x41/0x41 [54.931182]? raw_rcv+0x292/0x292 [54.931617]? nf_conntrack_confirm+0xa2/0xa2 [54.932158]? skb_sec_path+0xd/0x3f [54.932610]? xfrmi_input+0x90/0xce [ 54.933066] xfrm4_esp_rcv+0x33/0x54 [ 54.933521] ip_protocol_deliver_rcu+0xd7/0x1b2 [ 54.934089] ip_local_deliver_finish+0x110/0x120 [ 54.93 4659] ? ip_protocol_deliver_rcu+0x1b2/0x1b2 [ 54.935248] NF_HOOK.constprop.0+0xf8/0x138 [ 54.935767] ? ip_sublist_rcv_finish+0x68/0x68 [54.936317]? ¿secure_tcpv6_ts_off+0x23/0x168 [54.936859]? ip_protocol_deliver_rcu+0x1b2/0x1b2 [54.937454]? __xfrm_policy_check2.constprop.0+0x18d/0x18d [ 54.938135] NF_HOOK.constprop.0+0xf8/0x138 [ 54.938663] ? ip_sublist_rcv_finish+0x68/0x68 [54.939220]? __xfrm_policy_check2.constprop.0+0x18d/0x18d [54.939904]? ip_local_deliver_finish+0x120/0x120 [ 54.940497] __netif_receive_skb_one_core+0xc9/0x107 [ 54.941121] ? __netif_receive_skb_list_core+0x1c2/0x1c2 [54.941771]? blk_mq_start_stopped_hw_queues+0xc7/0xf9 [54.942413]? blk_mq_start_stopped_hw_queue+0x38/0x38 [54.943044]? virtqueue_get_buf_ctx+0x295/0x46b [ 54.943618] Process_backlog+0xb3/0x187 [ 54.944102] __napi_poll.constprop.0+0x57/0x1a7 [ 54.944669] net_rx_action+0x1cb/0x380 [ 54.94 5150] ? __napi_poll.constprop.0+0x1a7/0x1a7 [54.945744]? vring_new_virtqueue+0x17a/0x17a [54.946300]? note_interrupt+0x2cd/0x367 [ 54.946805] handle_softirqs+0x13c/0x2c9 [ 54.947300] do_softirq+0x5f/0x7d [ 54.947727] [ 54.948014] [ 54.948300] _enable_ip+0x48/0x62 [ 54.948832] __neigh_event_send+0x3fd/0x4ca [ 54.949361] neigh_resolve_output+0x1e/0x210 [ 54.949896] ip_finish_output2+0x4bf/0x4f0 [ 54.950410] ? __ip_finish_output+0x171/0x1b8 [ 54.950956] ip_send_skb+0x25/0x57 [ 54.951390] raw_sendmsg+0xf95/0x10c0 [ 54.951850] ? check_new_pages+0x45/0x71 [ 54.952343] ? raw_hash_sk+0x21b/0x21b [54.952815]? kernel_init_pages+0x42/0x51 [54.953337]? prep_new_page+0x44/0x51 [54.953811]? get_page_from_freelist+0x72b/0x915 [54.954390]? signal_pending_state+0x77/0x77 [54.954936]? preempt_count_sub+0x14/0xb3 [54.955450]? __might_resched+0x8a/0x240 [ 54.955951] ? __might_sleep+0x25/0xa0 [ 54.956424] ? first_zones_zonelist+0x2c/0x43 [ 54.956977] ? __rcu_read_lock+0x2d/0x3a [ 54.957476] ? __pte_offset_map+0x32/0xa4 [54.957980]? __might_resched+0x8a/0x240 [ 54.958483] ? __might_sleep+0x25/0xa0 [ 54.958963] ? inet_send_prepare+0x54/0x54 [54.959478]? sock_sendmsg_nosec+0x42/0x6c [ 54.960000] sock_sendmsg_nosec+0x42/0x6c [ 54.960502] __sys_sendto+0x15d/0x1cc [ 54.960966] ? __x64_sys_getpeername+0x44/0x44 [ 54.961522] ? __handle_mm_fault+0x679/0xae4 [ 54.962068] ? find_vma+0x6b/0x ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: cfg80211: maneja la asignación de 2x996 RU en cfg80211_calculate_bitrate_he() Actualmente, NL80211_RATE_INFO_HE_RU_ALLOC_2x996 no se maneja en cfg80211_calculate_bitrate_he(), lo que genera la siguiente advertencia: kernel: invalid HE MCS: bw:6, ru :6 kernel: ADVERTENCIA: CPU: 0 PID: 2312 en net/wireless/util.c:1501 cfg80211_calculate_bitrate_he+0x22b/0x270 [cfg80211] Solucionelo manejando la asignación de 2x996 RU de la misma manera que el ancho de banda de 160 MHz.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mlxsw: espectro_acl_erp: corrige la advertencia de anidamiento de objetos. Las ACL en Spectrum-2 y los ASIC más nuevos pueden residir en el TCAM algorítmico (A-TCAM) o en el TCAM de circuito ordinario (C-TCAM). El primero puede contener más ACL (es decir, filtros tc), pero el número de máscaras en cada región (es decir, cadena tc) es limitado. Para mitigar los efectos de la limitación anterior, el dispositivo permite que los filtros compartan una única máscara si sus máscaras solo difieren en hasta 8 bits consecutivos. Por ejemplo, dst_ip/25 se puede representar usando dst_ip/24 con un delta de 1 bit. C-TCAM no tiene un límite en la cantidad de máscaras que se utilizan (y por lo tanto no admite la agregación de máscaras), pero puede contener una cantidad limitada de filtros. El controlador utiliza la librería "objagg" para realizar la agregación de máscaras pasándole objetos que constan de la máscara del filtro y si el filtro se insertará en la A-TCAM o en la C-TCAM, ya que los filtros en diferentes TCAM no pueden compartir una máscara. El conjunto de objetos creados depende del orden de inserción de los filtros y no es necesariamente óptimo. Por lo tanto, el controlador solicitará periódicamente a la librería que calcule un conjunto más óptimo ("sugerencias") observando todos los objetos existentes. Cuando la librería pregunta al controlador si se pueden agregar dos objetos, el controlador solo compara las máscaras proporcionadas e ignora la indicación A-TCAM/C-TCAM. Esto es lo correcto ya que el objetivo es mover tantos filtros como sea posible a la A-TCAM. El driver también prohíbe agregar dos máscaras idénticas, ya que esto solo puede suceder si una se colocó intencionalmente en la C-TCAM para evitar un conflicto en la A-TCAM. Lo anterior puede dar como resultado el siguiente conjunto de sugerencias: H1: {máscara X, A-TCAM} -> H2: {máscara Y, A-TCAM} // X es Y + delta H3: {máscara Y, C-TCAM} -> H4: {máscara Z, A-TCAM} // Y es Z + delta Después de obtener las sugerencias de la librería, el controlador comenzará a migrar filtros de una región a otra mientras consulta las sugerencias calculadas e indica al dispositivo que realice una búsqueda. en ambas regiones durante la transición. Suponiendo que se está migrando un filtro con máscara X a la A-TCAM en la nueva región, la búsqueda de sugerencias devolverá H1. Dado que H2 es el padre de H1, la librería intentará encontrar el objeto asociado con él y crearlo si es necesario, en cuyo caso se realizará otra búsqueda de sugerencias (recursiva). Esta búsqueda de sugerencias para {máscara Y, A-TCAM} devolverá H2 o H3 ya que el controlador pasa a la librería una función de comparación de objetos que ignora la indicación A-TCAM/C-TCAM. En última instancia, esto puede conducir a objetos anidados que no son compatibles con la librería [1]. Para solucionarlo, elimine la función de comparación de objetos tanto del controlador como de la librería, ya que el controlador era el único usuario. De esa forma, la búsqueda solo arrojará coincidencias exactas. No tengo un reproductor confiable que pueda reproducir el problema de manera oportuna, pero antes de solucionarlo, el problema se reproducía en varios minutos y con la solución no se reproduce en más de una hora. Tenga en cuenta que la utilidad actual de las sugerencias es limitada porque incluyen la indicación C-TCAM y representan una agregación que en realidad no puede ocurrir. Esto se abordará en net-next. [1] ADVERTENCIA: CPU: 0 PID: 153 en lib/objagg.c:170 objagg_obj_parent_assign+0xb5/0xd0 Módulos vinculados en: CPU: 0 PID: 153 Comm: kworker/0:18 No contaminado 6.9.0-rc6-custom -g70fbc2c1c38b #42 Nombre del hardware: Mellanox Technologies Ltd. MSN3700C/VMOD0008, BIOS 5.11 10/10/2018 Cola de trabajo: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work RIP: 0010:objagg_obj_parent_assign+0xb5/0xd0 [...] Seguimiento de llamadas: < TAREA> ---truncado----

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: wifi: ath12k: cambia la dirección de DMA al mapear paquetes reinyectados. Para paquetes fragmentados, ath12k vuelve a ensamblar cada fragmento como un paquete normal y luego lo reinyecta en el anillo HW. En este caso, la dirección DMA debe ser DMA_TO_DEVICE, no DMA_FROM_DEVICE. De lo contrario, se puede reinyectar una carga útil no válida en el HW y posteriormente entregarla al host. Dado que se puede asignar memoria arbitraria al búfer skb, falta conocimiento sobre los datos contenidos en el búfer reinyectado. En consecuencia, existe el riesgo de que se filtre información privada. Probado en: QCN9274 hw2.0 PCI WLAN.WBE.1.1.1-00209-QCAHKSWPL_SILICONZ-1

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: exec: corrige ToCToU entre la verificación permanente y el uso de set-uid/gid Al abrir un archivo para exec a través de do_filp_open(), la verificación de permisos se realiza con los metadatos del archivo en ese momento, y en caso de éxito, se devuelve un puntero de archivo. Mucho más adelante en la ruta del código execve(), los metadatos del archivo (específicamente modo, uid y gid) se utilizan para determinar si y cómo configurar uid y gid. Sin embargo, es posible que esos valores hayan cambiado desde la verificación de permisos, lo que significa que la ejecución puede obtener privilegios no deseados. Por ejemplo, si un archivo pudiera cambiar los permisos de ejecutable y no de set-id: ---------x 1 root root 16048 7 de agosto 13:16 destino a set-id y no ejecutable: ---S ------ 1 root root 16048 7 de agosto 13:16 target es posible obtener privilegios de root cuando la ejecución no debería haberse permitido. Si bien esta condición de ejecución es poco común en escenarios del mundo real, se ha observado (y se ha demostrado que es explotable) cuando los administradores de paquetes actualizan los bits setuid de los programas instalados. Dichos archivos comienzan siendo ejecutables mundialmente, pero luego se ajustan para que sean ejecutables en grupo con un bit set-uid. Por ejemplo, "chmod ox,u+s target" hace que "target" sea ejecutable sólo mediante uid "root" y gid "cdrom", y al mismo tiempo se convierte en setuid-root: -rwxr-xr-x 1 root cdrom 16048 7 de agosto de 13: 16 objetivo se convierte en: -rwsr-xr-- 1 cdrom raíz 16048 7 de agosto 13:16 objetivo Pero competir con el chmod significa que los usuarios sin membresía del grupo "cdrom" pueden obtener permiso para ejecutar "destino" justo antes del chmod, y cuando el chmod finaliza, el ejecutivo llega a brpm_fill_uid() y realiza el setuid como root, violando la autorización expresa de "sólo los miembros del grupo cdrom pueden setuid como root". Vuelva a verificar que todavía tengamos permisos de ejecución en caso de que los metadatos hayan cambiado. Sería mejor conservar una copia del momento de verificación permanente, pero hasta que podamos hacer esa refactorización, la opción menos mala es hacer una llamada completa a inode_permission() (bajo bloqueo de inodo). Se entiende que esto es seguro contra bloqueos mutuos, pero no es óptimo.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: perf: corrige la fuga de eventos al liberar el archivo y el ejecutable. El trabajo de la tarea pendiente de rendimiento nunca se espera hasta que se libere el evento correspondiente. En el caso de un evento secundario, publicado directamente a través de free_event(), esto puede potencialmente resultar en un evento filtrado, como en el siguiente escenario que ni siquiera requiere una implementación de trabajo IRQ débil para activarse: Schedule() prepare_task_switch() =======> perf_event_overflow() evento->pending_sigtrap = ... irq_work_queue(&event->pending_irq) <======= perf_event_task_sched_out() event_sched_out() evento-> pendiente_sigtrap = 0; atomic_long_inc_not_zero(&event->refcount) task_work_add(&event->pending_task) Finish_lock_switch() =======> perf_pending_irq() //no hacer nada, confiar en el trabajo de la tarea pendiente <======= < /IRQ> comenzar_new_exec() perf_event_exit_task() perf_event_exit_event() // Si es un evento secundario free_event() WARN(atomic_long_cmpxchg(&event->refcount, 1, 0) != 1) // el evento se filtró También pueden ocurrir escenarios similares con perf_event_remove_on_exec () o simplemente contra perf_event_release() concurrente. Solucione este problema sincronizando con el trabajo de tarea pendiente posiblemente restante mientras se libera el evento, tal como se hace con el trabajo de IRQ pendiente restante. Esto significa que la devolución de llamada de la tarea pendiente no necesita ni debe contener una referencia al evento, lo que impide que se libere.