Vulnerabilidades

MicroDicom DICOM Viewer versiones 2023.3 (compilación 9342) y anteriores se ven afectadas por una vulnerabilidad de desbordamiento de búfer de almacenamiento dinámico, que podría permitir a un atacante ejecutar código arbitrario en instalaciones afectadas de DICOM Viewer. Un usuario debe abrir un archivo DCM malicioso para poder explotar la vulnerabilidad.

MicroDicom DICOM Viewer versiones 2023.3 (compilación 9342) y anteriores contienen una falta de validación adecuada de los datos proporcionados por el usuario, lo que podría provocar daños en la memoria dentro de la aplicación.

Se encontró una vulnerabilidad en Netentsec NS-ASG Application Security Gateway 6.3. Ha sido clasificada como crítica. Una función desconocida del archivo /admin/list_localuser.php es afectada por esta vulnerabilidad. La manipulación del argumento ResId conduce a la inyección de SQL. Es posible lanzar el ataque de forma remota. El exploit ha sido divulgado al público y puede utilizarse. El identificador de esta vulnerabilidad es VDB-255300. NOTA: Se contactó primeramente con el proveedor sobre esta divulgación, pero no respondió de ninguna manera.

Se encontró una vulnerabilidad en Netentsec NS-ASG Application Security Gateway 6.3. Ha sido declarada crítica. Una función desconocida del archivo /admin/list_ipAddressPolicy.php es afectada por esta vulnerabilidad. La manipulación del argumento GroupId conduce a la inyección de SQL. El ataque se puede lanzar de forma remota. El exploit ha sido divulgado al público y puede utilizarse. A esta vulnerabilidad se le asignó el identificador VDB-255301. NOTA: Se contactó primeramente con el proveedor sobre esta divulgación, pero no respondió de ninguna manera.

La versión de sesión 1.17.5 permite obtener archivos de aplicaciones internas y archivos públicos del dispositivo del usuario sin el consentimiento del usuario. Esto es posible porque la aplicación es vulnerable a la lectura de archivos locales a través de archivos adjuntos del chat.

La versión 1.5.10 de Recipes permite realizar solicitudes HTTP arbitrarias a través del servidor. Esto es posible porque la aplicación es vulnerable a SSRF.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: rtw88: corrige el desbordamiento de la matriz en rtw_get_tx_power_params() Al utilizar un kernel con el Verificador de estado de comportamiento indefinido (UBSAN) habilitado, se registra el siguiente desbordamiento de la matriz: ======== ==================================================== ====================== UBSAN: índice de matriz fuera de los límites en /home/finger/wireless-drivers-next/drivers/net/wireless /realtek/rtw88/phy.c:1789:34 el índice 5 está fuera de rango para el tipo 'u8 [5]' CPU: 2 PID: 84 Comm: kworker/u16:3 Tainted: GO 5.12.0-rc5-00086- gd88bba47038e-dirty #651 Nombre del hardware: TOSHIBA TECRA A50-A/TECRA A50-A, BIOS versión 4.50 29/09/2014 Cola de trabajo: phy0 ieee80211_scan_work [mac80211] Seguimiento de llamadas: dump_stack+0x64/0x7c ubsan_epilogue+0x5/0x40 __ubsan _handle_out_of_bounds.cold +0x43/0x48 rtw_get_tx_power_params+0x83a/drivers/net/wireless/realtek/rtw88/0xad0 [rtw_core] ? rtw_pci_read16+0x20/0x20 [rtw_pci] ? check_hw_ready+0x50/0x90 [rtw_core] rtw_phy_get_tx_power_index+0x4d/0xd0 [rtw_core] rtw_phy_set_tx_power_level+0xee/0x1b0 [rtw_core] rtw_set_channel+0xab/0x110 [rtw_core] rtw_ops_config+0x87/0xc 0 [rtw_core] ieee80211_hw_config+0x9d/0x130 [mac80211] ieee80211_scan_state_set_channel+ 0x81/0x170 [mac80211] ieee80211_scan_work+0x19f/0x2a0 [mac80211] Process_one_work+0x1dd/0x3a0 trabajador_thread+0x49/0x330? hilo_rescate+0x3a0/0x3a0 kthread+0x134/0x150 ? kthread_create_worker_on_cpu+0x70/0x70 ret_from_fork+0x22/0x30 ========================================== ========================================= Se muestra la declaración donde se está invadiendo una matriz en el siguiente fragmento: if (rate <= DESC_RATE11M) tx_power = pwr_idx_2g->cck_base[group]; else ====> tx_power = pwr_idx_2g->bw40_base[grupo]; Las matrices asociadas se definen en main.h de la siguiente manera: struct rtw_2g_txpwr_idx { u8 cck_base[6]; u8 bw40_base[5]; estructura rtw_2g_1s_pwr_idx_diff ht_1s_diff; estructura rtw_2g_ns_pwr_idx_diff ht_2s_diff; estructura rtw_2g_ns_pwr_idx_diff ht_3s_diff; estructura rtw_2g_ns_pwr_idx_diff ht_4s_diff; }; El problema surge porque el valor del grupo es 5 para el canal 14. El aumento trivial en la dimensión de bw40_base falla ya que esta estructura debe coincidir con el diseño de efuse. La solución es agregar la tasa como argumento a rtw_get_channel_group() y configurar el grupo para el canal 14 en 4 si la tasa <= DESC_RATE11M. Este parche corrige la confirmación fa6dfe6bff24 ("rtw88: resolver el orden de las rutinas de configuración de energía de transmisión")

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: async_xor: aumenta src_offs al eliminar la página de destino. Ahora admitimos compartir una página si PAGE_SIZE no tiene el mismo tamaño de banda. Para respaldar esto, debe admitir el cálculo del valor xor con diferentes compensaciones para cada r5dev. Se utiliza una matriz de desplazamiento para registrar esos desplazamientos. En el modo RMW, la página de paridad se utiliza como página de origen. Establece ASYNC_TX_XOR_DROP_DST antes de calcular el valor xor en ops_run_prexor5. Por lo tanto, es necesario agregar src_list y src_offs al mismo tiempo. Ahora sólo necesita src_list. Entonces el valor xor que se calcula es incorrecto. Puede causar problemas de corrupción de datos. Puedo reproducir este problema al 100% en una máquina POWER8. Los pasos son: mdadm -CR /dev/md0 -l5 -n3 /dev/sdb1 /dev/sdc1 /dev/sdd1 --size=3G mkfs.xfs /dev/md0 mount /dev/md0 /mnt/test mount: /mnt/test: la llamada al sistema mount(2) falló: la estructura necesita limpieza.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: soc/tegra: regulators: se corrigió el bloqueo cuando la dispersión de voltaje está fuera de rango. Se corrigió el bloqueo del acoplador de voltaje que ocurre cuando la dispersión de voltaje está fuera de rango debido a un error en el código. . El requisito de dispersión máxima se tendrá en cuenta cuando el regulador de CPU no tenga consumidores. Este problema se observa en la consola de juegos Tegra30 Ouya una vez que se habilita DVFS en todo el sistema en un árbol de dispositivos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/nfc: corrige use-after-free llcp_sock_bind/connect Commits 8a4cd82d ("nfc: corrige la fuga de refcount en llcp_sock_connect()") y c33b1cc62 ("nfc: corrige la fuga de refcount en llcp_sock_bind()") corrigió un error de fuga de recuento en bind/connect pero introdujo un Use-After-Free si el mismo local está asignado a 2 sockets diferentes. Esto puede activarse mediante el siguiente programa simple: int sock1 = socket( AF_NFC, SOCK_STREAM, NFC_SOCKPROTO_LLCP ); int sock2 = conector (AF_NFC, SOCK_STREAM, NFC_SOCKPROTO_LLCP); memset( &addr, 0, sizeof(struct sockaddr_nfc_llcp) ); addr.sa_family = AF_NFC; addr.nfc_protocol = NFC_PROTO_NFC_DEP; bind( sock1, (struct sockaddr*) & addr, sizeof(struct sockaddr_nfc_llcp) ) bind( sock2, (struct sockaddr*) & addr, sizeof(struct sockaddr_nfc_llcp) ) close(sock1); cerrar(calcetín2); Solucione este problema asignando NULL a llcp_sock->local después de llamar a nfc_llcp_local_put. Esto aborda CVE-2021-23134.

dp-golang es un módulo Puppet para instalaciones Go. Antes de 1.2.7, dp-golang podía instalar archivos, incluido el binario del compilador, con la propiedad incorrecta cuando Puppet se ejecutaba como root y el paquete instalado era En macOS: vaya a la versión 1.4.3 a 1.21rc3, inclusive, go1.4 -bootstrap-20170518.tar.gz o go1.4-bootstrap-20170531.tar.gz. El usuario y el grupo especificados en el código Puppet se ignoraron para los archivos dentro del archivo. La versión 1.2.7 de dp-puppet recreará las instalaciones si el propietario o grupo de cualquier archivo o directorio dentro de esa instalación no coincide con el propietario o grupo solicitado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: spi: corrige el Use-After-Free con devm_spi_alloc_* No podemos confiar en el contenido de la lista devres durante spi_unregister_controller(), ya que la lista ya está eliminada en ese momento. Realizamos devres_find() para devm_spi_release_controller. Esto hace que los dispositivos registrados con devm_spi_alloc_{master,slave}() se identifiquen erróneamente como dispositivos heredados, no administrados por devm y sus contadores de referencia disminuyan por debajo de 0. ------------[ cortar aquí ] ------------ ADVERTENCIA: CPU: 1 PID: 660 en lib/refcount.c:28 refcount_warn_saturate+0x108/0x174 [] (refcount_warn_saturate) de [] (kobject_put+ 0x90/0x98) [] (kobject_put) de [] (put_device+0x20/0x24) r4:b6700140 [] (put_device) de [] (devm_spi_release_controller+0x3c/0x40 ) [ ] (devm_spi_release_controller) de [] (release_nodes+0x84/0xc4) r5:b6700180 r4:b6700100 [] (release_nodes) de [] (devres_release_all+0x5c/0x6 0) r8:b1638c54 r7:b117ad94 r6:b1638c10 r5:b117ad94 r4:b163dc10 [] (devres_release_all) de [] (__device_release_driver+0x144/0x1ec) r5:b117ad94 r4:b163dc10 [] (__device_release_driver) de [< b044f70c>] (device_driver_detach+0x84/0xa0) r9:00000000 r8:00000000 r7:b117ad94 r6:b163dc54 r5:b1638c10 r4:b163dc10 [] (device_driver_detach) de [ ] (unbind_store+0xe4/0xf8) en su lugar , determine el estado de asignación devm como un indicador en el controlador que se garantiza que será estable durante la limpieza.