Vulnerabilidades

Spring Cloud Data Flow es un procesamiento de datos por lotes y streaming basado en microservicios en Cloud Foundry y Kubernetes. El servidor Skipper tiene la capacidad de recibir solicitudes de carga de paquetes. Sin embargo, debido a una sanitización inadecuada de la ruta de carga, un usuario malintencionado que tenga acceso a la API del servidor skipper puede utilizar una solicitud de carga manipulada para escribir un archivo arbitrario en cualquier ubicación del sistema de archivos e incluso puede comprometer el servidor.

Vulnerabilidad de autorización faltante en ThimPress LearnPress. Este problema afecta a LearnPress: desde n/a hasta 4.2.3.

Vulnerabilidad de autorización faltante en Saturday Drive Ninja Forms. Este problema afecta a Ninja Forms: desde n/a hasta 3.6.25.

Vulnerabilidad de autorización faltante en Artbees JupiterX Core. Este problema afecta a JupiterX Core: desde 3.0.0 hasta 3.3.0.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: RDMA/mlx5: Se corrigió la liberación de memoria no asignada en el flujo de MR dereg. Para el caso de IB_MR_TYPE_DM, mr no tiene un umem, aunque sea un usuario MR. Esto hace que la función mlx5_free_priv_descs() piense que es un MR del kernel, lo que lleva a un acceso incorrecto a mr->descs que obtendrá valores incorrectos en la unión, lo que lleva a intentar liberar recursos que no fueron asignados en primer lugar. Por ejemplo: DMA-API: mlx5_core 0000:08:00.1: el controlador de dispositivo intenta liberar la memoria DMA que no ha asignado [dirección del dispositivo=0x0000000000000000] [tamaño=0 bytes] ADVERTENCIA: CPU: 8 PID: 1021 en kernel/dma/ debug.c:961 check_unmap+0x54f/0x8b0 RIP: 0010:check_unmap+0x54f/0x8b0 Seguimiento de llamadas: debug_dma_unmap_page+0x57/0x60 mlx5_free_priv_descs+0x57/0x70 [mlx5_ib] [mlx5_ib] ib_dereg_mr_user+0x60/0x140 [ib_core ] uverbs_destroy_uobject+0x59/0x210 [ib_uverbs] uobj_destroy+0x3f/0x80 [ib_uverbs] ib_uverbs_cmd_verbs+0x435/0xd10 [ib_uverbs] ? uverbs_finalize_object+0x50/0x50 [ib_uverbs] ? lock_acquire+0xc4/0x2e0? lock_adquirido+0x12/0x380? lock_acquire+0xc4/0x2e0? lock_acquire+0xc4/0x2e0? ib_uverbs_ioctl+0x7c/0x140 [ib_uverbs] ? lock_release+0x28a/0x400 ib_uverbs_ioctl+0xc0/0x140 [ib_uverbs]? ib_uverbs_ioctl+0x7c/0x140 [ib_uverbs] __x64_sys_ioctl+0x7f/0xb0 do_syscall_64+0x38/0x90 Soluciónelo reorganizando el flujo de dereg y la estructura mlx5_ib_mr: - Mueva el campo ib_umem a la estructura MRs del usuario en la unión, ya que solo se aplica allí. - La función mlx5_ib_dereg_mr() ahora llamará a mlx5_free_priv_descs() solo en caso de que no haya udata, lo que indica que no se trata de un usuario MR.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: RDMA: corrige el use-after-free en rxe_queue_cleanup En la ruta de manejo de errores en rxe_qp_from_init() qp->sq.queue se libera y luego rxe_create_qp() eliminará la última referencia a este objeto. La función de limpieza qp intentará liberar esta cola una vez y provocará un error UAF. Solucionarlo poniendo a cero el puntero de la cola después de liberar la cola en rxe_qp_from_init().

Vulnerabilidad de falta de autorización en Hennessey Digital Attorney. Este problema afecta a Attorney: desde n/a hasta 3.

Vulnerabilidad de Cross-Site Request Forgery (CSRF) en GamiPress. Este problema afecta a GamiPress: desde n/a hasta 2.5.6.

Vulnerabilidad de autorización faltante en ThimPress LearnPress. Este problema afecta a LearnPress: desde n/a hasta 4.2.3.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: vduse: corrige corrupción de memoria en vduse_dev_ioctl() El "config.offset" proviene del usuario. Es necesario realizar un control para evitar que esté fuera de los límites. Las variables "config.offset" y "dev->config_size" son ambas del tipo u32. Entonces, si el desplazamiento está fuera de los límites, entonces la resta "dev->config_size - config.offset" da como resultado un valor u32 muy alto. El desplazamiento fuera de los límites puede provocar daños en la memoria.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: netlink: af_netlink: Evite el skb vacío agregando una marca en len. Agregar una verificación en el parámetro len para evitar skb vacío. Esto evita un error de división en la función netem_enqueue que se produce cuando skb->len=0 y skb->data_len=0 en el paso de corrupción aleatoria como se muestra a continuación. skb->datos[prandom_u32() % skb_headlen(skb)] ^= 1<<(prandom_u32() % 8); Informe de fallo: [343.170349] netdevsim netdevsim0 netdevsim3: establecer [1, 0] tipo 2 familia 0 puerto 6081 - 0 [343.216110] netem: versión 1.3 [343.235841] error de división: 0000 [#1] PREEMPT SMP KASAN NOPTI [ 80] CPU : 3 PID: 4288 Comm: reproductor No contaminado 5.16.0-rc1+ [ 343.237569] Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 01/04/2014 [ 343.238707] RIP: 0010:netem_enqueue+0x1590/0x33c0 [sch_netem] [ 343.239499] Código: 89 85 58 ff ff ff e8 5f 5d e9 d3 48 8b b5 48 ff ff ff 8b 8d 50 ff ff 8b 85 58 ff ff 4 8 8b bd 70 y sigs. ff ff 31 d2 2b 4f 74 f1 48 b8 00 00 00 00 00 fc ff df 49 01 d5 4c 89 e9 48 c1 e9 03 [ 343.241883] RSP: 0018:ffff88800bcd7368 EFLAGS: 46 [343.242589] RAX: 00000000ba7c0a9c RBX: 0000000000000001 RCX: 0000000000000000 [ 343.243542] RDX: 0000000000000000 RSI: ffff88800f8edb10 RDI: ffff88800f8eda40 [ 343.244474] RBP: ff88800bcd7458 R08: 0000000000000000 R09: ffffffff94fb8445 [ 343.245403] R10: ffffffff94fb8336 R11: ffffffff94fb8445 R12: 0000000000000000 [ 343. 246355] R13: ffff88800a5a7000 R14: ffff88800a5b5800 R15 : 0000000000000020 [ 343.247291] FS: 00007fdde2bd7700(0000) GS:ffff888109780000(0000) knlGS:0000000000000000 [ 343.248350] CS: 0010 DS: 000 ES: 0000 CR0: 0000000080050033 [ 343.249120] CR2: 00000000200000c0 CR3: 000000000ef4c000 CR4: 00000000000006e0 [ 343.250076] Seguimiento de llamadas: [ 343.250423] [ 343.250713] ? memcpy+0x4d/0x60 [343.251162]? netem_init+0xa0/0xa0 [sch_netem] [ 343.251795] ? __sanitizer_cov_trace_pc+0x21/0x60 [ 343.252443] netem_enqueue+0xe28/0x33c0 [sch_netem] [ 343.253102] ? stack_trace_save+0x87/0xb0 [343.253655]? filter_irq_stacks+0xb0/0xb0 [343.254220]? netem_init+0xa0/0xa0 [sch_netem] [ 343.254837] ? __kasan_check_write+0x14/0x20 [343.255418]? _raw_spin_lock+0x88/0xd6 [ 343.255953] dev_qdisc_enqueue+0x50/0x180 [ 343.256508] __dev_queue_xmit+0x1a7e/0x3090 [ 343.257083] ? netdev_core_pick_tx+0x300/0x300 [343.257690]? check_kcov_mode+0x10/0x40 [343.258219]? _raw_spin_unlock_irqrestore+0x29/0x40 [343.258899]? __kasan_init_slab_obj+0x24/0x30 [343.259529] ? setup_object.isra.71+0x23/0x90 [343.260121]? nueva_losa+0x26e/0x4b0 [ 343.260609] ? kasan_poison+0x3a/0x50 [ 343.261118] ? kasan_unpoison+0x28/0x50 [343.261637]? __kasan_slab_alloc+0x71/0x90 [343.262214]? memcpy+0x4d/0x60 [343.262674]? write_comp_data+0x2f/0x90 [343.263209]? __kasan_check_write+0x14/0x20 [343.263802]? __skb_clone+0x5d6/0x840 [343.264329]? __sanitizer_cov_trace_pc+0x21/0x60 [ 343.264958] dev_queue_xmit+0x1c/0x20 [ 343.265470] netlink_deliver_tap+0x652/0x9c0 [ 343.266067] netlink_unicast+0x5a0/0x7f0 [ 343. 266608] ? netlink_attachskb+0x860/0x860 [343.267183]? __sanitizer_cov_trace_pc+0x21/0x60 [ 343.267820] ? write_comp_data+0x2f/0x90 [343.268367] netlink_sendmsg+0x922/0xe80 [343.268899]? netlink_unicast+0x7f0/0x7f0 [343.269472]? __sanitizer_cov_trace_pc+0x21/0x60 [343.270099] ? write_comp_data+0x2f/0x90 [343.270644]? netlink_unicast+0x7f0/0x7f0 [343.271210] sock_sendmsg+0x155/0x190 [343.271721] ____sys_sendmsg+0x75f/0x8f0 [343.272262] ? kernel_sendmsg+0x60/0x60 [343.272788]? write_comp_data+0x2f/0x90 [343.273332]? write_comp_data+0x2f/0x90 [ 343.273869] ___sys_sendmsg+0x10f/0x190 [ 343.274405] ? sendmsg_copy_msghdr+0x80/0x80 [343.274984]? slab_post_alloc_hook+0x70/0x230 [343.275597]? futex_wait_setup+0x240/0x240 [343.276175]? security_file_alloc+0x3e/0x170 [343.276779]? write_comp_d ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: corrige la fuga de dirección del kernel en el registro auxiliar r0 de atomic cmpxchg. La implementación de BPF_CMPXCHG en un nivel alto tiene los siguientes parámetros: .-[old-val] .-[new-val ] BPF_R0 = cmpxchg{32,64}(DST_REG + insn->off, BPF_R0, SRC_REG) `-[mem-loc] `-[old-val] Dado un BPF insn solo puede tener dos registros (dst, src), el R0 es fijo y se utiliza como registro auxiliar para la entrada (valor anterior), así como para la salida (devolver el valor anterior desde la ubicación de la memoria). Si bien el verificador realiza una serie de comprobaciones de seguridad, no rechaza los programas sin privilegios donde R0 contiene un puntero como valor antiguo. A través de la fuerza bruta, en mi máquina se necesitan aproximadamente 16 segundos para filtrar un puntero del kernel con BPF_CMPXCHG. Básicamente, PoC busca direcciones del kernel almacenando la dirección adivinada en la ranura del mapa como un escalar y usando el puntero del valor del mapa como R0, mientras que SRC_REG tiene un valor canario para detectar una dirección coincidente. Solucionelo comprobando R0 en busca de punteros y rechácelo si ese es el caso de los programas sin privilegios.