Vulnerabilidades

Si a un atacado se le dio acceso a una instancia con la función de administrador o administrador, no existe una autenticación de backend que impida que el atacado cree un nuevo usuario con una función de "administrador" y luego pueda usar esta nueva cuenta para tener privilegios elevados en la instancia

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: cifs: Reparar UAF en cifs_demultiplex_thread() Hay un UAF cuando xfstests en cifs: ERROR: KASAN: use-after-free en smb2_is_network_name_deleted+0x27/0x160 Lectura de tamaño 4 en addr ffff888810103fc08 por tarea cifsd/923 cpu: 1 pid: 923 com: cifsd no contaminado 6.1.0-rc4+ #45 ... llamar a la llamada: dump_stack_lvl+0x34/0x44 print_report+0x171/0x472 kasan_raport+0xad/0x130 kasan_range_range_range_range_range_range_mad/0xad/0xad/0xad/0xad/0xad/0xad/0xad/0xad/0xad/0xad/0xad/0xad/0xy 0x145/0x1a0 smb2_is_network_name_deleted+0x27/0x160 cifs_demultiplex_thread.cold+0x172/0x5a4 kthread+0x165/0x1a0 ret_from_fork+0x1f/0x30 Asignado por la tarea 923: kasan_save_stack+0x1e/ 0x40 kasan_set_track+0x21/0x30 __kasan_slab_alloc+0x54/0x60 kmem_cache_alloc +0x147/0x320 mempool_alloc+0xe1/0x260 cifs_small_buf_get+0x24/0x60 allocate_buffers+0xa1/0x1c0 cifs_demultiplex_thread+0x199/0x10d0 kthread+0x165/0x1a0 ret_from_fork+0x1f/0x30 Liberado por tarea 921: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_save_free_info +0x2a/0x40 ____kasan_slab_free+0x143/0x1b0 kmem_cache_free+0xe3/0x4d0 cifs_small_buf_release+0x29/0x90 SMB2_negotiate+0x8b7/0x1c60 smb2_negotiate+0x51/0x70 cifs_negotiate_protocol+0xf 0/0x160 cifs_get_smb_ses+0x5fa/0x13c0 mount_get_conns+0x7a/0x750 cifs_mount+0x103/0xd00 cifs_smb3_do_mount +0x1dd/0xcb0 smb3_get_tree+0x1d5/0x300 vfs_get_tree+0x41/0xf0 path_mount+0x9b3/0xdd0 __x64_sys_mount+0x190/0x1d0 do_syscall_64+0x35/0x80 Entry_SYSCALL_64_after_hwframe+0x46/0 xb0 La UAF es porque: mount(pid: 921) | cifsd(pid: 923) -------------------------------|------------ ------------------- | cifs_demultiplex_thread SMB2_negotiate | cifs_send_recv | compuesto_send_recv | smb_send_rqst | esperar_para_respuesta | esperar_event_state [1] | | recepción_estándar3 | cifs_handle_standard | manejar_mid | mid->resp_buf = buf; [2] | dequeue_mid [3] MATAR el proceso [4] | resp_iov[i].iov_base = buf | free_rsp_buf [5] | | is_network_name_eliminado [6] | devolución de llamada 1. Después de enviar la solicitud al servidor, espere la respuesta hasta mid->mid_state != ENVIADO; 2. Reciba la respuesta del servidor y configúrelo en medio; 3. Establezca el estado medio en RECIBIDO; 4. Finalice el proceso, el estado medio ya RECIBIDO, obtenga 0; 5. Manejar y liberar la respuesta de negociación; 6. UAF. Se puede reproducir fácilmente agregando algo de retraso en [3] - [6]. Solo la llamada de sincronización tiene el problema ya que la devolución de llamada de la llamada asíncrona se ejecuta en el proceso cifsd. Agregue un estado adicional para marcar el estado medio como LISTO antes de despertar al camarero, luego podrá obtener la respuesta de manera segura.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: HID: intel-ish-hid: ipc: Deshabilita y vuelve a habilitar el bit ACPI GPE Las plataformas basadas en EHL (Elkhart Lake) proporcionan un servicio OOB (Fuera de banda), que permite despertar dispositivo cuando el sistema está en S5 (estado Soft-Off). Este servicio OOB se puede habilitar/deshabilitar desde la configuración del BIOS. Cuando está habilitado, el dispositivo ISH obtiene la capacidad de activación PME. Para habilitar la activación de PME, el controlador también debe habilitar el bit ACPI GPE. Al reanudar, el BIOS borrará el bit de activación. Por lo tanto, el controlador debe volver a habilitarlo en la función de reanudación para mantener la siguiente capacidad de activación. Pero esta limpieza del bit de activación del BIOS no disminuye el recuento de referencias GPE del sistema operativo interno, por lo que esta reactivación en cada reanudación provocará que el recuento de referencias se desborde. Entonces, primero deshabilite y vuelva a habilitar el bit ACPI GPE usando acpi_disable_gpe().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: plataforma/x86: think-lmi: corregir fuga de referencia Si se encuentra un atributo duplicado usando kset_find_obj(), se devuelve una referencia a ese atributo que debe eliminarse en consecuencia usando kobject_put( ). Mueva la validación del nombre de la configuración a una función separada para permitir este cambio sin tener que duplicar el código de limpieza para esta configuración. Como nota al margen, se solucionó un error muy similar en el commit 7295a996fdab ("plataforma/x86: dell-sysman: corregir fuga de referencia"), por lo que parece que el error se copió de ese controlador. Compilación probada únicamente.

*** Pendiente de traducción *** Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: soluciona el posible desgarro del almacén en neigh_periodic_work() Mientras miraba un informe de syzbot relacionado que involucraba a neigh_periodic_work(), descubrí que olvidé agregar una anotación al eliminar un elemento protegido por RCU de una lista. Los lectores usan rcu_deference(*np), necesitamos usar rcu_assign_pointer() o WRITE_ONCE() en el lado del escritor para evitar que la tienda se rompa. Utilizo rcu_assign_pointer() para tener soporte lockdep, esta fue la elección hecha en neigh_flush_dev().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf, sockmap: rechaza las redirecciones de salida de sk_msg a sockets que no son TCP. Con un mapa SOCKMAP/SOCKHASH y un programa sk_msg, el usuario puede dirigir los mensajes enviados desde un socket TCP (s1) para que realmente salgan desde otro socket TCP (s2): tcp_bpf_sendmsg(s1) // = sk_prot->sendmsg tcp_bpf_send_verdict(s1) // __SK_REDIRECT caso tcp_bpf_sendmsg_redir(s2) tcp_bpf_push_locked(s2) tcp_bpf_push(s2) tcp_rate_check_ app_limited(s2) // espera tcp_sock tcp_sendmsg_locked(s2 ) // ídem Hay una suposición codificada en la cadena de llamadas de que el socket de salida (s2) es un socket TCP. Sin embargo, en el commit 122e6c79efe1 ("sock_map: Actualizar comprobaciones de tipo de calcetín para UDP") hemos habilitado redirecciones a sockets que no son TCP. Esto se hizo por el bien de los programas BPF sk_skb. No había ninguna sangría para admitir el caso de uso de envío a salida de sk_msg. Como resultado, los intentos de envío a salida a través de un socket que no es TCP provocan un bloqueo debido a una conversión no válida de sock a tcp_sock: ERROR: desreferencia del puntero NULL del núcleo, dirección: 0000000000000002f... Seguimiento de llamadas: . mostrar_regs+0x60/0x70? __die+0x1f/0x70 ? page_fault_oops+0x80/0x160? do_user_addr_fault+0x2d7/0x800? rcu_is_watching+0x11/0x50? exc_page_fault+0x70/0x1c0? asm_exc_page_fault+0x27/0x30? tcp_tso_segs+0x14/0xa0 tcp_write_xmit+0x67/0xce0 __tcp_push_pending_frames+0x32/0xf0 tcp_push+0x107/0x140 tcp_sendmsg_locked+0x99f/0xbb0 tcp_bpf_push+0x19d/0x3a0 tcp_bpf_sendmsg_redir+0x55/0xd0 tcp_bpf_send_verdict+0x407/0x550 tcp_bpf_sendmsg+0x1a1/0x390 inet_sendmsg+0x6a/0x70 sock_sendmsg+0x9d/0xc0? sockfd_lookup_light+0x12/0x80 __sys_sendto+0x10e/0x160 ? syscall_enter_from_user_mode+0x20/0x60? __this_cpu_preempt_check+0x13/0x20? lockdep_hardirqs_on+0x82/0x110 __x64_sys_sendto+0x1f/0x30 do_syscall_64+0x38/0x90 Entry_SYSCALL_64_after_hwframe+0x63/0xcd Rechace la selección de sockets que no sean TCP como destino de redireccionamiento desde un programa BPF sk_msg para evitar el bloqueo. Cuando lo intente, el usuario recibirá un error EACCES de la llamada al sistema send/sendto/sendmsg().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: nfc: llcp: Agregar bloqueo al modificar la lista de dispositivos La lista de dispositivos necesita mantener su bloqueo asociado al modificarla, o la lista podría corromperse, como descubrió syzbot.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mwifiex: corrige la condición de verificación de oob en mwifiex_process_rx_packet Solo omita la ruta del código al intentar acceder a los encabezados rfc1042 cuando el búfer sea demasiado pequeño, para que el controlador aún pueda procesar paquetes sin encabezados rfc1042 .

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: erofs: corrige la pérdida de memoria de la deduplicación comprimida global LZMA Al estresar las imágenes microLZMA EROFS con la nueva función de deduplicación comprimida global habilitada (`-Ededupe`), encontré algunas páginas temporales de corta duración no se publicaron correctamente, lo que podría causar OOM inesperados horas más tarde. Solucionémoslo ahora (LZ4 y DEFLATE no tienen este problema).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipv4, ipv6: se corrigió el manejo de transhdrlen en __ip{,6}_append_data() Incluir el transhdrlen en longitud es un problema cuando el paquete está parcialmente lleno (por ejemplo, algo como enviar(MSG_MORE ) sucedió anteriormente) al agregarlo a un paquete IPv4 o IPv6, ya que no queremos repetir el encabezado de transporte ni contabilizarlo dos veces. Esto puede suceder en algunas circunstancias, como al realizar un empalme en un zócalo L2TP. El síntoma observado es una advertencia en __ip6_append_data(): ADVERTENCIA: CPU: 1 PID: 5042 en net/ipv6/ip6_output.c:1800 __ip6_append_data.isra.0+0x1be8/0x47f0 net/ipv6/ip6_output.c:1800 que ocurre cuando MSG_SPLICE_PAGES se utiliza para agregar más datos a un skbuff que ya está parcialmente ocupado. La advertencia se produce cuando 'copiar' es mayor que la cantidad de datos en el iterador del mensaje. Esto se debe a que la longitud solicitada incluye la longitud del encabezado de transporte cuando no debería hacerlo. Esto puede desencadenarse, por ejemplo: sfd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_L2TP); enlazar(sfd, ...); // ::1 conectar(sfd, ...); // ::1 puerto 7 enviar(sfd, buffer, 4100, MSG_MORE); enviar archivo (sfd, dfd, NULL, 1024); Solucione este problema agregando solo transhdrlen a la longitud si la cola de escritura está vacía en l2tp_ip6_sendmsg(), de manera análoga a cómo hace las cosas UDP. Parece que l2tp_ip_sendmsg() no sufrirá este problema ya que construye el paquete UDP por sí mismo.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: usb: smsc75xx: corrigió el acceso a valores uninit en __smsc75xx_read_reg syzbot informó el siguiente problema de acceso a valores uninit: =============== ====================================== ERROR: KMSAN: valor uninit en controladores smsc75xx_wait_ready/net /usb/smsc75xx.c:975 [en línea] ERROR: KMSAN: valor uninit en smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482 CPU: 0 PID: 8696 Comm: kworker/0:3 No contaminado 5.8.0-rc5-syzkaller #0 Nombre del hardware: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Cola de trabajo: usb_hub_wq hub_event Seguimiento de llamadas: __dump_stack lib/dump_stack.c:77 [en línea] dump_stack+0x21c/ 0x280 lib/dump_stack.c:118 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:121 __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215 smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [en línea ] smsc75xx_bind+0x5c9/0x11e0 controladores/net/usb/smsc75xx.c:1482 usbnet_probe+0x1152/0x3f90 controladores/net/usb/usbnet.c:1737 usb_probe_interface+0xece/0x1550 controladores/usb/core/driver.c:374 very_probe +0xf20/0x20b0 controladores/base/dd.c:529 driver_probe_device+0x293/0x390 controladores/base/dd.c:701 __device_attach_driver+0x63f/0x830 controladores/base/dd.c:807 bus_for_each_drv+0x2ca/0x3f0 controladores/base/ bus.c:431 __device_attach+0x4e2/0x7f0 controladores/base/dd.c:873 dispositivo_initial_probe+0x4a/0x60 controladores/base/dd.c:920 bus_probe_device+0x177/0x3d0 controladores/base/bus.c:491 dispositivo_add+0x3b0e /0x40d0 controladores/base/core.c:2680 usb_set_configuration+0x380f/0x3f10 controladores/usb/core/message.c:2032 usb_generic_driver_probe+0x138/0x300 controladores/usb/core/generic.c:241 usb_probe_device+0x311/0x490 controladores/ usb/core/driver.c:272 Actually_probe+0xf20/0x20b0 controladores/base/dd.c:529 driver_probe_device+0x293/0x390 controladores/base/dd.c:701 __device_attach_driver+0x63f/0x830 controladores/base/dd.c: 807 bus_for_each_drv+0x2ca/0x3f0 controladores/base/bus.c:431 __device_attach+0x4e2/0x7f0 controladores/base/dd.c:873 device_initial_probe+0x4a/0x60 controladores/base/dd.c:920 bus_probe_device+0x177/0x3d0 controladores/ base/bus.c:491 dispositivos_add+0x3b0e/0x40d0 controladores/base/core.c:2680 usb_new_device+0x1bd4/0x2a30 controladores/usb/core/hub.c:2554 hub_port_connect controladores/usb/core/hub.c:5208 [ en línea] hub_port_connect_change drivers/usb/core/hub.c:5348 [en línea] port_event drivers/usb/core/hub.c:5494 [en línea] hub_event+0x5e7b/0x8a70 drivers/usb/core/hub.c:5576 Process_one_work+ 0x1688/0x2140 kernel/workqueue.c:2269 trabajador_thread+0x10bc/0x2730 kernel/workqueue.c:2415 kthread+0x551/0x590 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293 Variable local ----buf.i87@smsc75xx_bind creada en: __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [en línea] smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [en línea] smsc75xx_bind+0x485/0x11e0 drivers /net/usb/smsc75xx.c:1482 __smsc75xx_read_reg controladores/net/usb/smsc75xx.c:83 [en línea] smsc75xx_wait_ready controladores/net/usb/smsc75xx.c:968 [en línea] smsc75xx_bind+0x485/0x11e0 controladores/net/usb /smsc75xx.c:1482 Este problema se debe a que usbnet_read_cmd() lee menos bytes de los solicitados (cero bytes en el reproductor). En este caso, 'buf' no se completa correctamente. Este parche soluciona el problema devolviendo -ENODATA si usbnet_read_cmd() lee menos bytes de los solicitados.