Vulnerabilidades

Vulnerabilidad de validación de entrada en la Ruleta de la Fortuna de Qualifio. Esta vulnerabilidad permite a un atacante modificar un correo electrónico para que contenga el símbolo ‘+’ para acceder a la aplicación y ganar premios tantas veces como desee.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: restablecer la capacidad de mapear asignaciones memfd selladas a escritura como de solo lectura Serie de parches "mm: restablecer la capacidad de mapear asignaciones memfd selladas a escritura como de solo lectura". En el commit 158978945f31 ("mm: realizar la comprobación mapping_map_writable() después de call_mmap()") (y cambios anteriores en la misma serie) se hizo posible mmap() F_SEAL_WRITE asignaciones memfd selladas como de solo lectura. El commit 5de195060b2e ("mm: resolver el comportamiento defectuoso de la ruta de error mmap_region()") deshizo involuntariamente esta lógica al mover la comprobación mapping_map_writable() antes de que se invoque el gancho shmem_mmap(), lo que hizo que este cambio retrocediera. Esta serie reelabora la forma en que permitimos que las asignaciones selladas de escritura se asignen a solo lectura y no permitimos que mprotect() deshaga el sello de escritura, solucionando esta regresión. También agregamos una prueba de regresión para asegurarnos de que no retrocedamos accidentalmente esto en el futuro. Gracias a Julian Orth por informar esta regresión. Este parche (de 2): En el commit 158978945f31 ("mm: realizar la comprobación mapping_map_writable() después de call_mmap()") (y cambios anteriores en la misma serie) se hizo posible mmap() asignaciones de memfd selladas de F_SEAL_WRITE a solo lectura. Esto anteriormente se deshabilitaba innecesariamente, a pesar de que la documentación de la página del manual indicaba que lo estaría, lo que limitaba la utilidad de la lógica de F_SEAL_WRITE. Hemos corregido esto adaptando la lógica que existía para el sello F_SEAL_FUTURE_WRITE (uno que no permite escrituras futuras en el memfd) para que también se use para F_SEAL_WRITE. En segundo plano, el sello F_SEAL_FUTURE_WRITE borra VM_MAYWRITE para una asignación de solo lectura para no permitir que mprotect() anule el sello, una operación realizada por seal_check_write(), invocada desde shmem_mmap(), el gancho f_op->mmap() utilizado por las asignaciones de shmem. Al extender esto a F_SEAL_WRITE y, críticamente, verificar mapping_map_writable() para determinar si podemos asignar el memfd DESPUÉS de invocar shmem_mmap(), la lógica deseada se vuelve posible. Esto se debe a que mapping_map_writable() verifica explícitamente VM_MAYWRITE, que habremos borrado. El commit 5de195060b2e ("mm: resolver el comportamiento de la ruta de error mmap_region() defectuoso") deshizo esta lógica sin querer al mover la comprobación mapping_map_writable() antes de que se invoque el gancho shmem_mmap(), lo que hace que este cambio se repita. Restablecemos esta funcionalidad al mover la comprobación de shmem_mmap() y, en su lugar, realizarla en do_mmap() en el punto en el que se están determinando los indicadores VMA, que parece ser, en cualquier caso, un lugar más apropiado para realizar esta determinación. Para lograr esto, rediseñamos la lógica del sello memfd para permitirnos acceder a esta información utilizando la lógica existente y eliminar la limpieza de VM_MAYWRITE de seal_check_write() que estamos realizando en do_mmap() en su lugar.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/sctp: Evitar el desbordamiento de enteros de cierre automático en sctp_association_init() Si bien, de forma predeterminada, max_autoclose es igual a INT_MAX / HZ, se puede establecer net.sctp.max_autoclose en UINT_MAX. Hay un código en sctp_association_init() que, en consecuencia, puede provocar un desbordamiento.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fgraph: Agregar READ_ONCE() al acceder a fgraph_array[] En __ftrace_return_to_handler(), un bucle itera sobre los elementos fgraph_array[], que son fgraph_ops. El bucle comprueba si un elemento es un fgraph_stub para evitar usar un fgraph_stub después. Sin embargo, si el compilador vuelve a cargar fgraph_array[] después de esta comprobación, podría competir con una actualización a fgraph_array[] que introduce un fgraph_stub. Esto podría dar como resultado que se procese el stub, pero que este contenga un campo "func_hash" nulo, lo que lleva a una desreferencia de puntero NULL. Para garantizar que los gops comparados con fgraph_stub coincidan con los gops procesados ??más tarde, agregue un READ_ONCE(). Un parche similar aparece en el commit 63a8dfb ("function_graph: Agregar READ_ONCE() al acceder a fgraph_array[]").

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: tracing: Hacer que process_string() también permita matrices Para detectar un error común en el que un TP_fast_assign() de TRACE_EVENT() asigna una dirección de una cadena asignada al búfer de anillo y luego la referencia en TP_printk(), que se puede ejecutar horas después cuando la cadena está libre, la función test_event_printk() se ejecuta en todos los eventos a medida que se registran para asegurarse de que no haya desreferenciaciones no deseadas. Llama a process_string() para gestionar los casos en formato TP_printk() que tienen "%s". Devuelve si la cadena es segura o no. Pero puede tener algunos falsos positivos. Por ejemplo, xe_bo_move() tiene: TP_printk("move_lacks_source:%s, migrate object %p [size %zu] from %s to %s device_id:%s", __entry->move_lacks_source ? "yes" : "no", __entry->bo, __entry->size, xe_mem_type_to_name[__entry->old_placement], xe_mem_type_to_name[__entry->new_placement], __get_str(device_id)) Where the "%s" Donde "%s" hace referencia a xe_mem_type_to_name[]. Esta es una matriz de punteros a los que el evento debería poder acceder de forma segura. En lugar de marcar esto como una referencia incorrecta, si una referencia apunta a una matriz, donde el campo de registro es el índice, considérela segura.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: selinux: ignorar permisos extendidos desconocidos Al evaluar permisos extendidos, ignorar permisos desconocidos en lugar de llamar a BUG(). Esta confirmación garantiza que se puedan agregar permisos futuros sin interferir con kernels más antiguos.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gve: guard XDP xmit NDO on existing xdp queues En GVE, las colas XDP dedicadas solo existen cuando se instala un programa XDP y la interfaz está activa. Como tal, la devolución de llamada NDO XDP XMIT debe regresar temprano si alguna de estas condiciones es falsa. En el caso de que no haya un programa XDP cargado, priv->num_xdp_queues=0 que puede causar un error de división por cero, y en el caso de que la interfaz esté inactiva, num_xdp_queues permanece intacto para persistir el conteo de colas XDP para la siguiente interfaz activa, pero el puntero TX en sí sería NULL. La devolución de llamada XDP xmit también necesita sincronizarse con un dispositivo que esté pasando de abierto a cerrado. Esta sincronización ocurrirá a través del bit GVE_PRIV_FLAGS_NAPI_ENABLED junto con una llamadasynchronous_net(), que espera a que se completen las secciones críticas de RCU en el momento de la llamada.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gve: proteger las operaciones XSK ante la existencia de colas Este parche predica la habilitación y deshabilitación de los grupos XSK ante la existencia de colas. Tal como está, si la interfaz está inactiva, deshabilitar o habilitar los grupos XSK provocaría un bloqueo, ya que el puntero de cola RX sería NULL. El registro del grupo XSK se producirá como parte de la siguiente interfaz activa. De forma similar, xsk_wakeup debe protegerse contra la desaparición de colas mientras se ejecuta la función, por lo que se agrega una comprobación contra el indicador GVE_PRIV_FLAGS_NAPI_ENABLED para sincronizar con la desactivación del bit y elsynchronous_net() en gve_turndown.

Una asignación de recursos sin límites ni constricción en Kibana puede provocar un bloqueo causado por una solicitud manipulado especial a /api/log_entries/summary. Esto lo pueden llevar a cabo los usuarios con acceso de lectura a la función Observability-Logs en Kibana.

El complemento Betheme para WordPress es vulnerable a Cross-Site Scripting Almacenado a través de la funcionalidad JS personalizada del complemento en todas las versiones hasta incluida, 27.6.1 debido a la falta de desinfección de entrada y el escape de salida en los atributos proporcionados por el usuario. Esto hace posible que los atacantes autenticados, con acceso de nivel de colaborador y superior, inyecten scripts web arbitraria en las páginas que se ejecutarán cada vez que un usuario acceda a una página inyectada.

El complemento wp-greet para WordPress es vulnerable a Cross-Site Request Forgery en todas las versiones hasta la 6.2 incluida. Esto se debe a la falta o la validación incorrecta de un nonce en una función. Esto permite que atacantes no autenticados actualicen configuraciones e inyecten scripts web maliciosos a través de una solicitud falsificada, siempre que puedan engañar al administrador de un sitio para que realice una acción como hacer clic en un enlace.

La gestión inadecuada de la codificación alternativa ocurre cuando Elastic Defend en sistemas Windows intenta escanear un archivo o proceso codificado como un carácter multibyte. Esto genera una excepción no detectada que hace que Elastic Defend se bloquee, lo que a su vez le impedirá poner en cuarentena el archivo o finalizar el proceso.