Vulnerabilidades

Una inclusión de archivo local (LFI) en Customer Support System v1 permite a los atacantes incluir archivos PHP internos y obtener acceso no autorizado mediante la manipulación del parámetro page= en /customer_support/index.php.

Una vulnerabilidad de listado de directorios en Customer Support System v1 permite a los atacantes enumerar directorios y archivos confidenciales dentro de la aplicación sin requerir autorización.

Una vulnerabilidad de Cross-Site Scripting en Petrol Pump Mangement Software v.1.0 permite a un atacante ejecutar código arbitrario a través de un payload manipulado en el parámetro Dirección en el componente add_invoices.php.

Vulnerabilidad de Cross-Site Scripting en Petrol Pump Mangement Software v.1.0 permite a un atacante ejecutar código arbitrario a través de un payload manipulado en el parámetro de imagen en el componente profile.php.

Vulnerabilidad de inyección SQL en Petrol Pump Mangement Software v.1.0 permite a un atacante ejecutar código arbitrario a través de un payload manipulado en el parámetro de dirección de correo electrónico en el componente index.php.

Vulnerabilidad de carga de archivos en Petrol Pump Mangement Software v.1.0 permite a un atacante ejecutar código arbitrario a través de un payload manipulado en el parámetro Imagen de correo electrónico en el componente profile.php.

Ciertos productos de impresión HP DesignJet son potencialmente vulnerables a la divulgación de información relacionada con el acceso a la memoria fuera de los límites cuando se utiliza la puerta de enlace de uso general (GGW) a través del puerto 9220.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: RDMA/rxe: devuelve un error de CQE si se proporcionó una clave lválida. A RXE le falta la actualización del estado de WQE en fallas LOCAL_WRITE. Esto provocó el siguiente pánico en el kernel si alguien enviaba una operación atómica con una clave l explícitamente incorrecta. [leonro@vm ~]$ mkt test test_atomic_invalid_lkey (tests.test_atomic.AtomicTest) ... ADVERTENCIA: CPU: 5 PID: 263 en drivers/infiniband/sw/rxe/rxe_comp.c:740 rxe_completer+0x1a6d/0x2e30 [rdma_rxe] Módulos vinculados en: crc32_generic rdma_rxe ip6_udp_tunnel udp_tunnel rdma_ucm rdma_cm ib_umad ib_ipoib iw_cm ib_cm mlx5_ib ib_uverbs ib_core mlx5_core ptp pps_core CPU: 5 PID: 263 Comm: python3 No contaminado 5.13.0-rc 1+ #2936 Nombre del hardware: PC estándar QEMU (Q35 + ICH9, 2009 ), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 01/04/2014 RIP: 0010:rxe_completer+0x1a6d/0x2e30 [rdma_rxe] Código: 03 0f 8e 65 0e 00 00 3b 93 10 06 00 0 0 0f 84 82 0a 00 00 4c 89 ff 4c 89 44 24 38 e8 2d 74 a9 e1 4c 8b 44 24 38 e9 1c f5 ff ff <0f> 0b e9 0c e8 ff ff b8 05 00 00 00 41 bf 05 00 0 0 00 e9 ab e7 ff RSP: 0018:ffff8880158af090 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888016a78000 RCX: ffffffffa0cf1652 RDX: 1ffff9200004b442 RSI: 0000000 000000004 RDI: ffffc9000025a210 RBP: dffffc0000000000 R08: 00000000ffffffea R09: ffff88801617740b R10: ffffed1002c2ee81 R11: 0000000000000007 R12: ffff 88800f3b63e8 R13: ffff888016a78008 R14: ffffc9000025a180 R15: 000000000000000c FS: 00007f88b622a740(0000) GS:ffff88806d540000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES : 0000 CR0: 0000000080050033 CR2: 00007f88b5a1fa10 CR3: 000000000d848004 CR4: 0000000000370ea0 DR0: 00000000000000000 DR1: 00000000000000000 DR 2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Seguimiento de llamadas: rxe_do_task+0x130/0x230 [rdma_rxe] rxe_rcv+0xb11/0x1d f0 [rdma_rxe] rxe_loopback+0x157/0x1e0 [rdma_rxe] rxe_responder+0x5532/0x7620 [rdma_rxe] rxe_do_task+0x130/0x230 [rdma_rxe] rxe_rcv+0x9c8/0x1df0 [rdma_rxe] rxe_loopback+0x157/0x1e0 [rdma_rxe] rxe_requester+0x1efd/0x58c0 [rdma_rxe] rxe_do_task+0x130/0x230 [rdma_rxe] r xe_post_send+0x998/0x1860 [rdma_rxe] ib_uverbs_post_send+0xd5f/0x1220 [ib_uverbs ] ib_uverbs_write+0x847/0xc80 [ib_uverbs] vfs_write+0x1c5/0x840 ksys_write+0x176/0x1d0 do_syscall_64+0x3f/0x80 Entry_SYSCALL_64_after_hwframe+0x44/0xae

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ipc/mqueue, msg, sem: evite confiar en una referencia de pila después de su vencimiento do_mq_timedreceive llama a wq_sleep con una dirección local de pila. El remitente (do_mq_timedsend) usa esta dirección para luego llamar a pipelined_send. Esto conduce a una ejecución muy difícil de desencadenar en la que una llamada do_mq_timedreceive puede regresar y dejar que do_mq_timedsend dependa de una dirección no válida, lo que provoca el siguiente bloqueo: RIP: 0010:wake_q_add_safe+0x13/0x60 Seguimiento de llamadas: __x64_sys_mq_timedsend+0x2a9/0x490 do_syscall_64+0x80 /0x680 Entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f5928e40343 La ejecución ocurre como: 1. do_mq_timedreceive llama a wq_sleep con la dirección de `struct ext_wait_queue` en la pila de funciones (alias `ewq_addr` aquí): contiene una `struct ext_wait_queue * válida ` siempre y cuando la pila no haya sido sobrescrita. 2. `ewq_addr` se agrega a info->e_wait_q[RECV].list en wq_add, y do_mq_timedsend lo recibe a través de wq_get_first_waiter(info, RECV) para llamar a __pipelined_op. 3. El remitente llama a __pipelined_op::smp_store_release(&this->state, STATE_READY). Aquí es donde comienza la ventana de ejecución. (`esto` es `ewq_addr`.) 4. Si el receptor se activa ahora en do_mq_timedreceive::wq_sleep, verá `state == STATE_READY` y se interrumpirá. 5. do_mq_timedreceive regresa y ya no se garantiza que `ewq_addr` sea una `struct ext_wait_queue *` ya que estaba en la pila de do_mq_timedreceive. (Aunque es posible que la dirección no se sobrescriba hasta que otra función la toque, lo que significa que puede persistir por un tiempo indefinido). 6. do_mq_timedsend::__pipelined_op() todavía cree que `ewq_addr` es una `struct ext_wait_queue *`, y lo usa para encontrar una task_struct para pasar a la llamada wake_q_add_safe. En el afortunado caso de que nada haya sobrescrito `ewq_addr` todavía, `ewq_addr->task` es la estructura de tarea correcta. En el desafortunado caso, __pipelined_op::wake_q_add_safe recibe una dirección falsa como la task_struct del receptor que causa el bloqueo. do_mq_timedsend::__pipelined_op() no debe eliminar la referencia a "esto" después de configurar STATE_READY, ya que la contraparte del receptor ahora puede regresar. Cambie __pipelined_op para llamar a wake_q_add_safe en el task_struct del receptor devuelto por get_task_struct, en lugar de desreferenciar "this" que se encuentra en la pila del receptor. Como señaló Manfred, la ejecución también existe potencialmente en ipc/msg.c::expunge_all e ipc/sem.c::wake_up_sem_queue_prepare. Arréglelos de la misma manera.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: uio_hv_generic: corrige una pérdida de memoria en las rutas de manejo de errores. Si falla 'vmbus_establecer_gpadl()', (recv|send)_gpadl no se actualizará y aparecerá 'hv_uio_cleanup()' en el error La ruta de manejo no podrá liberar el búfer correspondiente. En tal caso, necesitamos liberar el búfer explícitamente.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: uio_hv_generic: soluciona otra pérdida de memoria en las rutas de manejo de errores. La memoria asignada por 'vmbus_alloc_ring()' al comienzo de la función de sondeo nunca se libera en la ruta de manejo de errores. Agregue la llamada 'vmbus_free_ring()' que falta. Tenga en cuenta que ya está liberado en la función .remove.

Un atacante remoto y no autenticado puede enviar mensajes manipulados al servidor web del Commend WS203VICM, lo que provoca que el sistema se reinicie e interrumpa el servicio.