Vulnerabilidades

En wolfSSL anterior a 5.6.6, si las funciones de devolución de llamada están habilitadas (a través del indicador WOLFSSL_CALLBACKS), entonces un cliente TLS malicioso o un atacante de red puede desencadenar una sobrelectura del búfer en el montón de 5 bytes (WOLFSSL_CALLBACKS solo está destinado a la depuración).

MantisBT es un rastreador de problemas de código abierto. Antes de la versión 2.26.1, un atacante no autenticado que conoce la dirección de correo electrónico y el nombre de usuario de un usuario puede secuestrar la cuenta del usuario envenenando el enlace en el mensaje de notificación de restablecimiento de contraseña. Hay un parche disponible en la versión 2.26.1. Como workaround, defina `$g_path` según corresponda en `config_inc.php`.

La vulnerabilidad de inyección SQL en MRCMS v3.1.2 permite a los atacantes ejecutar comandos arbitrarios del sistema a través del parámetro de estado.

kedi ElectronCord es una herramienta de gestión de bots para Discord. El commit aaaeaf4e6c99893827b2eea4dd02f755e1e24041 expone un token de acceso a la cuenta en el archivo `config.json`. Los actores malintencionados podrían explotar esta vulnerabilidad para obtener acceso no autorizado a información confidencial o realizar acciones maliciosas en nombre del propietario del repositorio. Al momento de la publicación, se desconoce si el propietario del repositorio rotó el token o tomó otras medidas de mitigación además de informar a los usuarios sobre la situación.

com.yetanalytics/lrs es la librería LRS principal de Yet Analytics. Antes de la versión 1.2.17 de la librería LRS y la versión 0.7.5 de SQL LRS, se podía utilizar una declaración xAPI creada con fines malintencionados para realizar una inyección de script u otras etiquetas en el navegador de declaraciones LRS. El problema se solucionó en la versión 1.2.17 de la librería LRS y en la versión 0.7.5 de SQL LRS. No existen workarounds conocidas.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: termina explícitamente en nulo la lista xattr Al configurar un xattr, termina explícitamente en nulo la lista xattr. Esto elimina la frágil suposición de que el espacio xattr no utilizado siempre se pone a cero.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: Revertir "md/raid5: Espere MD_SB_CHANGE_PENDING en raid5d" Esto revierte El commit 5e2cf333b7bd5d3e62595a44d598a254c697cd74. Ese commit introdujo la siguiente ejecución y puede provocar que el sistema se cuelgue. md_write_start: raid5d: // mddev->in_sync == 1 set "MD_SB_CHANGE_PENDING" // ejecutándose antes de que md_write_start se despierte esperando "MD_SB_CHANGE_PENDING" borrado >>>>>>>>> colgado despertar mddev->thread ... esperando "MD_SB_CHANGE_PENDING "borrado >>>> colgado, raid5d debería borrar esta bandera pero quedar colgado por la misma bandera. El problema de corrección de commit revertido se solucionó con el último parche de una manera nueva.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: binder: corrige el use-after-free en la devolución de llamada de shinker. El bloqueo de lectura mmap se usa durante la devolución de llamada de shrinker, lo que significa que usar el puntero alloc->vma no es seguro ya que puede ejecutarse con munmap(). A partir de el commit dd2283f2605e ("mm: mmap: zap páginas con lectura mmap_sem en munmap"), el bloqueo mmap se degrada después de que se ha aislado el vma. Pude reproducir este problema agregando manualmente algunos retrasos y activando la recuperación de páginas a través del sistema de depuración del reductor. El siguiente informe de KASAN confirma la UAF: =========================================== ======================== ERROR: KASAN: slab-use-after-free en zap_page_range_single+0x470/0x4b8 Lectura de tamaño 8 en la dirección ffff356ed50e50f0 por tarea bash/478 CPU: 1 PID: 478 Comm: bash No contaminado 6.6.0-rc5-00055-g1c8b86a3799f-dirty #70 Nombre de hardware: linux,dummy-virt (DT) Rastreo de llamadas: zap_page_range_single+0x470/0x4b8 binder_alloc_free_page+0x608/ 0xadc __list_lru_walk_one+0x130/0x3b0 list_lru_walk_node+0xc4/0x22c binder_shrink_scan+0x108/0x1dc encogimiento_debugfs_scan_write+0x2b4/0x500 full_proxy_write+0xd4/0x140 vfs_write+0x1ac/0x758 ksys_write+0xf0/0x1dc __arm64_sys_write+0x6c/0x9c Asignado por la tarea 492: kmem_cache_alloc+0x130/ 0x368 vm_area_alloc+0x2c/0x190 mmap_region+0x258/0x18bc do_mmap+0x694/0xa60 vm_mmap_pgoff+0x170/0x29c ksys_mmap_pgoff+0x290/0x3a0 __arm64_sys_mmap+0xcc/0x144 Liberado por tarea 491: kmem_cache_free+0x17c/0x3c8 vm_area_free_rcu_cb+0x74/0x98 rcu_core+0xa38/ 0x26d4 rcu_core_si+0x10/0x1c __do_softirq+0x2fc/0xd24 Última creación de trabajo potencialmente relacionado: __call_rcu_common.constprop.0+0x6c/0xba0 call_rcu+0x10/0x1c vm_area_free+0x18/0x24 remove_vma+0xe4/0x118 do_vmi _align_munmap.isra.0+0x718/0xb5c do_vmi_munmap+0xdc/0x1fc __vm_munmap+0x10c/0x278 __arm64_sys_munmap+0x58/0x7c Solucione este problema realizando en su lugar un vma_lookup() que no podrá encontrar el vma que estaba aislado antes de la degradación del bloqueo mmap. Tenga en cuenta que esta opción tiene un mejor rendimiento que actualizar a un bloqueo de escritura mmap, lo que aumentaría la contención. Además, mmap_write_trylock() se eliminó recientemente de todos modos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: uio: corrige use-after-free en uio_open core-1 core-2 ------------------------------------------------------- uio_unregister_device uio_open idev = idr_find() device_unregister(&idev->dev) put_device(&idev->dev) uio_device_release get_device(&idev->dev) kfree(idev) uio_free_minor(minor) uio_release put_device(&idev->dev) kfree(idev) ------------------------------------------------------- In the core-1 uio_unregister_device(), the device_unregister se liberará idev cuando la referencia del objeto idev->dev kobject es 1. But after core-1 device_unregister, put_device and before doing kfree, the core-2 may get_device. Then: 1. After core-1 kfree idev, the core-2 will do use-after-free for idev. 2. When core-2 do uio_release and put_device, el idev se liberará dos veces. Para solucionar este problema, podemos obtener la referencia de idev atomic & inc idev con minor_lock.

Cuando se habilitó SSL para Mongo Hook, la configuración predeterminada incluía "allow_insecure", lo que provocaba que los certificados no se validaran. Esto fue inesperado e indocumentado. Se recomienda a los usuarios actualizar a la versión 4.0.0, que soluciona este problema.

Una vulnerabilidad de Cross-site scripting en la función de sanitización en Enhancesoft osTicket 1.18.0 permite a un atacante remoto escalar privilegios a través de un ticket de soporte manipulado.

Vulnerabilidad de Cross Site Scripting (XSS) en ProjeQtOr 11.0.2 permite a un atacante remoto ejecutar código arbitrario a través de un script manipulado para la función checkvalidHtmlText en los archivos ack.php y security.php.