Vulnerabilidades

MyBB es un software de foro gratuito y de código abierto. El módulo de gestión de copias de seguridad del Admin CP puede aceptar `.htaccess` como nombre del archivo de copia de seguridad que se eliminará, lo que puede exponer los archivos de copia de seguridad almacenados a través de HTTP en servidores Apache. MyBB 1.8.38 resuelve este problema. Se recomienda a los usuarios que actualicen. No se conocen workarounds para esta vulnerabilidad

MyBB es un software de foro gratuito y de código abierto. La lista predeterminada de hosts remotos no permitidos no contiene el bloque `127.0.0.0/8`, lo que puede provocar una vulnerabilidad de Server Side Request Forgery (SSRF). La lista de _Direcciones remotas no permitidas_ del archivo de configuración ("$config['disallowed_remote_addresses']`) contiene la dirección `127.0.0.1`, pero no incluye el bloque completo `127.0.0.0/8`. MyBB 1.8.38 resuelve este problema en las instalaciones predeterminadas. Los administradores de las placas instaladas deben actualizar la configuración existente (`inc/config.php`) para incluir todas las direcciones bloqueadas de forma predeterminada. Además, se recomienda a los usuarios que verifiquen que incluya otras direcciones IPv4 que se resuelvan en el servidor y otros recursos internos. Los usuarios que no puedan actualizar pueden agregar manualmente 127.0.0.0/8' a su lista de direcciones no permitidas.

RIOT es un sistema operativo multiproceso en tiempo real que admite una variedad de dispositivos que suelen ser microcontroladores de 8, 16 y 32 bits. La función `_on_rd_init()` no implementa una verificación de tamaño antes de copiar datos al búfer estático `_result_buf`. Si un atacante puede crear un payload lo suficientemente larga, podría provocar un desbordamiento del búfer. Si la entrada no verificada anterior está controlada por un atacante y cruza un límite de seguridad, el impacto de la vulnerabilidad de desbordamiento del búfer podría variar desde denegación de servicio hasta ejecución de código arbitrario. Este problema aún no se ha solucionado. Se recomienda a los usuarios que agreguen la verificación manual de los límites.

Static Web Server (SWS) es un pequeño y rápido servidor web listo para producción, adecuado para servir archivos o activos web estáticos. En las versiones afectadas, si los listados de directorios están habilitados para un directorio para el que un usuario que no es de confianza tiene privilegios de carga, un nombre de archivo malicioso como `.txt` permitirá la ejecución de código JavaScript en el contexto de el dominio del servidor web. SWS generalmente no realiza escapes de entidades HTML en ningún valor insertado en la lista del directorio. Sin embargo, al menos `file_name` y `current_path` podrían contener datos maliciosos. `file_uri` también podría ser malicioso, pero todos los escenarios relevantes parecen ser detectados por hyper. Para cualquier servidor web que permita a los usuarios cargar archivos o crear directorios con el nombre de su elección, esto se convierte en una vulnerabilidad de Cross Site Scripting almacenada. Se recomienda a los usuarios que actualicen. No se conocen workarounds para esta vulnerabilidad.

El complemento Geo Controller WordPress anterior a 8.6.5 deserializa la entrada del usuario a través de algunas de sus acciones AJAX y rutas API REST, lo que podría permitir a usuarios no autenticados realizar inyección de objetos PHP cuando hay un gadget adecuado presente en el blog.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: fork: posponga la vinculación del archivo vma hasta que vma esté completamente inicializado. Thorvald informó una ADVERTENCIA [1]. Y la causa raíz está por debajo de la raza: CPU 1 CPU 2 fork hugetlbfs_fallocate dup_mmap hugetlbfs_punch_hole i_mmap_lock_write(mapping); vma_interval_tree_insert_after: el vma secundario es visible a través del árbol i_mmap. i_mmap_unlock_write(mapeo); enormetlb_dup_vma_private: ¡borre vma_lock fuera de i_mmap_rwsem! i_mmap_lock_write(mapeo); Hugetlb_vmdelete_list vma_interval_tree_foreach Hugetlb_vma_trylock_write: Vma_lock está borrado. tmp->vm_ops->open - ¡Asigne nuevo vma_lock fuera de i_mmap_rwsem! enormetlb_vma_unlock_write - ¡¡¡Vma_lock está asignado!!! i_mmap_unlock_write(mapeo); Hugetlb_dup_vma_private() y hugetlb_vm_op_open() se llaman fuera del bloqueo i_mmap_rwsem, mientras que el bloqueo vma se puede utilizar al mismo tiempo. Solucione este problema posponiendo la vinculación del archivo vma hasta que vma esté completamente inicializado. Esos vmas deben inicializarse primero antes de poder usarlos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5e: evita el interbloqueo al deshabilitar aRFS. Al deshabilitar aRFS bajo `priv->state_lock`, cualquier trabajo de aRFS programado se cancela usando la función `cancel_work_sync`, que espera la trabajo para terminar si ya ha comenzado. Sin embargo, mientras espera el controlador de trabajo, el controlador intentará adquirir el `state_lock` que ya está adquirido. El trabajador adquiere el bloqueo para eliminar las reglas si el estado está inactivo, lo cual no es responsabilidad del trabajador ya que al desactivar aRFS se eliminan las reglas. Agregue una variable de estado de aRFS, que indica si aRFS está habilitado y evita agregar reglas cuando aRFS está deshabilitado. Registro del kernel: ================================================= ======= ADVERTENCIA: posible dependencia de bloqueo circular detectada 6.7.0-rc4_net_next_mlx5_5483eb2 #1 Contaminado: GI -------------------- ---------------------- ethtool/386089 está intentando adquirir el bloqueo: ffff88810f21ce68 ((work_completion)(&rule->arfs_work)){ +.+.}-{0:0}, en: __flush_work+0x74/0x4e0 pero la tarea ya mantiene el bloqueo: ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, en: mlx5e_ethtool_set_channels+ 0x53/0x200 [mlx5_core] cuyo bloqueo ya depende del nuevo bloqueo. la cadena de dependencia existente (en orden inverso) es: -> #1 (&priv->state_lock){+.+.}-{3:3}: __mutex_lock+0x80/0xc90 arfs_handle_work+0x4b/0x3b0 [mlx5_core] Process_one_work+0x1dc /0x4a0 work_thread+0x1bf/0x3c0 kthread+0xd7/0x100 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20 -> #0 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}: __lock_acquire+0x17b4/0x2c80 lock_acquire+0xd0/0x2b0 __flush_work+0x7a/0x4e0 __cancel_work_timer+0x131/0x1c0 arfs_del_rules+0x143/0x1e0 [mlx5_core] mlx5e_arfs_disable+0x1b/0x30 mlx5_core] mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core] ethnl_set_channels+0x28f/0x3b0 ethnl_default_set_doit +0xec/0x240 genl_family_rcv_msg_doit+0xd0/0x120 genl_rcv_msg+0x188/0x2c0 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x1a1/0x270 netlink_sendmsg+0x214/0 x460 __sock_sendmsg+0x38/0x60 __sys_sendto+0x113/0x170 __x64_sys_sendto+0x20/0x30 do_syscall_64 +0x40/0xe0 Entry_SYSCALL_64_after_hwframe+0x46/0x4e otra información que podría ayudarnos a depurar esto: Posible escenario de bloqueo inseguro: CPU0 CPU1 ---- ---- lock(&priv->state_lock); lock((work_completion)(&rule->arfs_work)); bloquear(&priv->state_lock); lock((work_completion)(&rule->arfs_work)); *** DEADLOCK *** 3 bloqueos retenidos por ethtool/386089: #0: ffffffff82ea7210 (cb_lock){++++}-{3:3}, en: genl_rcv+0x15/0x40 #1: ffffffff82e94c88 (rtnl_mutex){ +.+.}-{3:3}, en: ethnl_default_set_doit+0xd3/0x240 #2: ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, en: mlx5e_ethtool_set_channels+0x53/0x200 [ mlx5_core] seguimiento de pila: CPU: 15 PID: 386089 Comm: ethtool Tainted: GI 6.7.0-rc4_net_next_mlx5_5483eb2 #1 Nombre de hardware: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt .qemu.org 01/04/2014 Seguimiento de llamadas: dump_stack_lvl+0x60/0xa0 check_noncircular+0x144/0x160 __lock_acquire+0x17b4/0x2c80 lock_acquire+0xd0/0x2b0? __flush_work+0x74/0x4e0? save_trace+0x3e/0x360? __flush_work+0x74/0x4e0 __flush_work+0x7a/0x4e0 ? __flush_work+0x74/0x4e0? __lock_acquire+0xa78/0x2c80? lock_acquire+0xd0/0x2b0? mark_held_locks+0x49/0x70 __cancel_work_timer+0x131/0x1c0 ? mark_held_locks+0x49/0x70 arfs_del_rules+0x143/0x1e0 [mlx5_core] mlx5e_arfs_disable+0x1b/0x30 [mlx5_core] mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core] ethnl_set_channels+0x28f/0x3b0 ethnl_default_set_doit+0xec/0x240 genl_family_rcv_msg_doit+0xd0/0x120 genl_rcv_msg+0x188/0x2c0 ? ethn ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: tabla de flujo: tupla de pppoe incorrecta. El tráfico de pppoe que llega a la ruta de entrada no coincide con la entrada de la tabla de flujo porque se espera que el encabezado de pppoe esté en el desplazamiento del encabezado de red. Este error provoca una discrepancia en la búsqueda de la tabla de flujo, por lo que los paquetes pppoe ingresan a la ruta de reenvío clásica.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: flowtable: validar encabezado pppoe Asegúrese de que haya suficiente espacio para acceder al campo de protocolo del encabezado PPPoe. Valídelo una vez antes de la búsqueda de la tabla de flujo, luego use una función auxiliar para acceder al campo de protocolo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netfilter: nft_set_pipapo: recorra la vista actual en el volcado de netlink. La máscara de generación se puede actualizar mientras el volcado de netlink está en progreso. El iterador de recorrido backend del conjunto pipapo no puede confiar en él para inferir qué vista de la estructura de datos se va a utilizar. Agregue notación para especificar si el usuario desea leer/actualizar el conjunto. Basado en un parche de Florian Westphal.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netfilter: br_netfilter: omitir el enlace de entrada conntrack para paquetes promiscos. Por razones históricas, cuando el dispositivo puente está en modo promisco, los paquetes que se dirigen a los taps siguen la ruta del enlace de entrada del puente. Este parche agrega una workaround para restablecer el seguimiento de conexión de estos paquetes. Jianbo Liu informa señales de advertencia en su infraestructura de prueba donde los paquetes clonados llegan al enlace de entrada br_netfilter para confirmar el objeto conntrack. Elimine un bit de BR_INPUT_SKB_CB para anotar que este paquete ha llegado al gancho de entrada porque pasa al dispositivo puente para llegar a las derivaciones. [57.571874] ADVERTENCIA: CPU: 1 PID: 0 en net/bridge/br_netfilter_hooks.c:616 br_nf_local_in+0x157/0x180 [br_netfilter] [57.572749] Módulos vinculados en: xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat escriba xt_conntrack nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry superposición rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_isc si ib_umad rdma_cm ib_ipoib iw_cm ib_cm mlx5_ib ib_uverbs ib_core mlx5ctl mlx5_core [ 57.575158] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.8.0+ #19 [ 57.575700] Nombre de hardware: PC estándar UEM (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 01/04/2014 [ 57.576662] RIP: 0010:br_nf_local_in+0x157/0x180 [br_netfilter] [ 57.577195] Código: fe ff ff 41 04 00 00 00 be 04 00 00 00 e9 4a ff ff ff be 04 00 00 00 48 89 ef e8 f3 a9 3c e1 66 83 ad b4 00 00 00 04 eb 91 <0f> 0b e9 f1 fe ff ff 0f 0b e9 df fe ff ff 48 89 df e8 b3 53 47 e1 [ 57.578722] RSP: 0018:ffff88885f845a08 EFLAGS: 00010202 [ 57.579207] RAX: 0000000000000002 RBX: ffff88812dfe8000 RCX: 0000000000000000 [ 57.579830] RDX: ffff88885f845a60 RSI: ffff8881022dc300 RDI: 0000000000000000 [ 57.580454] RBP: ffff88885f845a60 R08: 0000000000000001 R09: 0000000000000003 [ 57.581076] R10: 00000000ffff1300 R11: 0000000000000002 R12: 0000000 [ 57.581695] R13: ffff8881047ffe00 R14: ffff888108dbee00 R15: ffff88814519b800 [ 57.582313] FS: 0000000000000000(0000) GS:ffff88885f8400 00(0000) knlGS:0000000000000000 [ 57.583040] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 57.583564] CR2: 000000c4206aa000 CR3: 0000000103847001 CR4: 0000000000370eb0 [ 57.584194] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 57.584820] DR3: 00000000000000000 DR6: 00000000ffe0ff0 0000000000000400 [ 57.585440] Seguimiento de llamadas: [ 57.585721] [ 57.585976] ? __advertir+0x7d/0x130 [ 57.586323] ? br_nf_local_in+0x157/0x180 [br_netfilter] [57.586811]? report_bug+0xf1/0x1c0 [57.587177]? handle_bug+0x3f/0x70 [57.587539]? exc_invalid_op+0x13/0x60 [57.587929]? asm_exc_invalid_op+0x16/0x20 [57.588336]? br_nf_local_in+0x157/0x180 [br_netfilter] [ 57.588825] nf_hook_slow+0x3d/0xd0 [ 57.589188] ? br_handle_vlan+0x4b/0x110 [ 57.589579] br_pass_frame_up+0xfc/0x150 [ 57.589970] ? br_port_flags_change+0x40/0x40 [ 57.590396] br_handle_frame_finish+0x346/0x5e0 [ 57.590837] ? ipt_do_table+0x32e/0x430 [57.591221]? br_handle_local_finish+0x20/0x20 [ 57.591656] br_nf_hook_thresh+0x4b/0xf0 [br_netfilter] [ 57.592286] ? br_handle_local_finish+0x20/0x20 [ 57.592802] br_nf_pre_routing_finish+0x178/0x480 [br_netfilter] [ 57.593348] ? br_handle_local_finish+0x20/0x20 [ 57.593782] ? nf_nat_ipv4_pre_routing+0x25/0x60 [nf_nat] [ 57.594279] br_nf_pre_routing+0x24c/0x550 [br_netfilter] [ 57.594780] ? br_nf_hook_thresh+0xf0/0xf0 [br_netfilter] [ 57.595280] br_handle_frame+0x1f3/0x3d0 [ 57.595676] ? br_handle_local_finish+0x20/0x20 [ 57.596118] ? br_handle_frame_finish+0x5e0/0x5e0 [ 57.596566] __netif_receive_skb_core+0x25b/0xfc0 [ 57.597017] ? __napi_build_skb+0x37/0x40 [ 57.597418] __netif_receive_skb_list_core+0xfb/0x220

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: netfilter: nf_tables: corrige una posible ejecución de datos en __nft_obj_type_get() nft_unregister_obj() puede concurrir con __nft_obj_type_get(), y no hay ninguna protección cuando se itera sobre la lista de nf_tables_objects en __nft_obj_type_get() . Por lo tanto, existe una posible ejecución de datos de la entrada de la lista nf_tables_objects. Utilice list_for_each_entry_rcu() para iterar sobre la lista nf_tables_objects en __nft_obj_type_get(), y utilice rcu_read_lock() en el llamador nft_obj_type_get() para proteger todo el proceso de consulta de tipos.