Vulnerabilidades

GitHub CLI es la herramienta de línea de comandos oficial de GitHub. Se ha identificado una vulnerabilidad de seguridad en GitHub CLI que podría crear o sobrescribir archivos en directorios no deseados cuando los usuarios descargan un artefacto de flujo de trabajo de GitHub Actions malicioso a través de gh run download. Esta vulnerabilidad se origina en un artefacto de flujo de trabajo de GitHub Actions llamado .. cuando se descarga usando gh run download. El nombre del artefacto y el indicador --dir se utilizan para determinar la ruta de descarga del artefacto. Cuando el artefacto se llama .., los archivos resultantes dentro del artefacto se extraen exactamente 1 directorio más arriba que el valor del indicador --dir especificado. Esta vulnerabilidad se corrigió en 2.63.1.

Una cuenta de acceso de publicación se vio comprometida para `@solana/web3.js`, una librería de JavaScript que se usa comúnmente en las dapps de Solana. Esto permitió a un atacante publicar paquetes no autorizados y maliciosos que fueron modificados, lo que les permitió robar material de claves privadas y drenar fondos de las dapps, como bots, que manejan claves privadas directamente. Este problema no debería afectar a las billeteras sin custodia, ya que generalmente no exponen claves privadas durante las transacciones. Este no es un problema con el protocolo Solana en sí, sino con una librería de cliente de JavaScript específica y solo parece afectar a los proyectos que manejan claves privadas directamente y que se actualizaron dentro de la ventana de las 3:20 p. m. UTC y las 8:25 p. m. UTC del martes 3 de diciembre de 2024. Estas dos versiones no autorizadas (1.95.6 y 1.95.7) fueron detectadas en cuestión de horas y desde entonces se han anulado. Todos los desarrolladores de aplicaciones de Solana deben actualizar a la versión 1.95.8. Los desarrolladores que sospechen que pueden estar comprometidos deben rotar todas las claves de autoridad sospechosas, incluidas las multifirmas, las autoridades del programa, los pares de claves del servidor, etc.

El complemento Accessibility by AllAccessible para WordPress es vulnerable a modificaciones no autorizadas de datos que pueden provocar una escalada de privilegios debido a una falta de verificación de capacidad en la función 'AllAccessible_save_settings' en todas las versiones hasta la 1.3.4 incluida. Esto permite que atacantes autenticados, con acceso de nivel de suscriptor y superior, actualicen opciones arbitrarias en el sitio de WordPress. Esto se puede aprovechar para actualizar el rol predeterminado para el registro como administrador y habilitar el registro de usuarios para que los atacantes obtengan acceso de usuario administrativo a un sitio vulnerable.

La aplicación Mister org.mistergroup.shouldianswer 1.4.264 para Android permite que cualquier aplicación instalada (sin permisos) realice llamadas telefónicas sin interacción del usuario enviando una intención manipulada a través del componente org.mistergroup.shouldianswer.ui.default_dialer.DefaultDialerActivity.

La aplicación GriceMobile com.grice.call 4.5.2 para Android permite que cualquier aplicación instalada (sin permisos) realice llamadas telefónicas sin interacción del usuario enviando una intención manipulada a través de com.iui.mobile.presentation.MobileActivity.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: netlink: termina el volcado pendiente al cerrar el socket Netlink admite el volcado iterativo de datos. Proporciona a las familias las siguientes operaciones: - start - (opcional) inicia el proceso de volcado - dump - asistente de volcado real, se sigue llamando hasta que devuelve 0 - done - (opcional) se empareja con .start, se puede usar para limpieza Todo el proceso es asincrónico y las llamadas repetidas a .dump en realidad no ocurren en un bucle cerrado, sino que se activan en respuesta a recvmsg() en el socket. Esto le da al usuario control total sobre el volcado, pero también significa que el usuario puede cerrar el socket sin llegar al final del volcado. Para asegurarnos de que .start siempre esté emparejado con .done, verificamos si hay un volcado en curso antes de liberar el socket y, si es así, llamamos a .done. La complicación es que los sockets pueden liberarse de BH y se permite que .done duerma. Entonces, usamos una cola de trabajo para diferir la llamada, cuando sea necesario. Lamentablemente, esto no funciona correctamente. Lo que postergamos no es la limpieza, sino la liberación de una referencia en el socket. No tenemos garantía de que seamos dueños de la última referencia; si alguien más tiene el socket, puede liberarlo en BH y volvemos al punto de partida. Sin embargo, todo el baile parece ser innecesario. Solo el usuario puede interactuar con los volcados, por lo que podemos limpiar cuando se cierra el socket. Y el cierre siempre ocurre en el contexto del proceso. Es posible que algún código asincrónico aún acceda al socket después del cierre, ponga en cola skbs de notificación, etc., pero ningún volcado puede comenzar, finalizar o avanzar de otro modo. Elimine la cola de trabajo y vacíe el estado del volcado directamente desde el controlador de liberación. Tenga en cuenta que es posible realizar una desinfección adicional en -next, por ejemplo, ahora siempre llamamos a .done antes de liberar la referencia del módulo principal, por lo que el volcado no tiene que tomar una referencia propia.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: sctp: corregir posible UAF en sctp_v6_available() Un informe de lockdep [1] con CONFIG_PROVE_RCU_LIST=y sugiere que sctp_v6_available() está llamando a dev_get_by_index_rcu() e ipv6_chk_addr() sin retener rcu. [1] ============================= ADVERTENCIA: uso sospechoso de RCU 6.12.0-rc5-virtme #1216 Tainted: GW ----------------------------- net/core/dev.c:876 ¡Lista de RCU recorrida en una sección que no es de lectura! Otra información que podría ayudarnos a depurar esto: rcu_scheduler_active = 2, debug_locks = 1 1 bloqueo mantenido por sctp_hello/31495: #0: ffff9f1ebbdb7418 (sk_lock-AF_INET6){+.+.}-{0:0}, en: sctp_bind (./arch/x86/include/asm/jump_label.h:27 net/sctp/socket.c:315) seguimiento de pila sctp: CPU: 7 UID: 0 PID: 31495 Comm: sctp_hello Contaminado: GW 6.12.0-rc5-virtme #1216 Contaminado: [W]=WARN Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 01/04/2014 Seguimiento de llamadas: dump_stack_lvl (lib/dump_stack.c:123) lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822) dev_get_by_index_rcu (net/core/dev.c:876 (discriminador 7)) sctp_v6_available (net/sctp/ipv6.c:701) sctp sctp_do_bind (net/sctp/socket.c:400 (discriminador 1)) sctp sctp_bind (net/sctp/socket.c:320) sctp inet6_bind_sk (net/ipv6/af_inet6.c:465) ? security_socket_bind (seguridad/seguridad.c:4581 (discriminador 1)) __sys_bind (red/socket.c:1848 red/socket.c:1869) ? do_user_addr_fault (./include/linux/rcupdate.h:347 ./include/linux/rcupdate.h:880 ./include/linux/mm.h:729 arch/x86/mm/fault.c:1340) ? do_user_addr_fault (./arch/x86/include/asm/preempt.h:84 (discriminador 13) ./include/linux/rcupdate.h:98 (discriminador 13) ./include/linux/rcupdate.h:882 (discriminador 13) ./include/linux/mm.h:729 (discriminador 13) arch/x86/mm/fault.c:1340 (discriminador 13)) __x64_sys_bind (net/socket.c:1877 (discriminador 1) net/socket.c:1875 (discriminador 1) net/socket.c:1875 (discriminador 1)) do_syscall_64 (arch/x86/entry/common.c:52 (discriminador 1) arch/x86/entry/common.c:83 (discriminador 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f59b934a1e7 Código: 44 00 00 48 8b 15 39 8c 0c 00 f7 d8 64 89 02 b8 ff ff ff ff ff eb bd 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 b8 31 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 09 8c 0c 00 f7 d8 64 89 01 48 Todo el código ======== 0: 44 00 00 agregar %r8b,(%rax) 3: 48 8b 15 39 8c 0c 00 mov 0xc8c39(%rip),%rdx # 0xc8c43 a: f7 d8 neg %eax c: 64 89 02 mov %eax,%fs:(%rdx) f: b8 ff ff ff ff mov $0xffffffff,%eax 14: eb bd jmp 0xffffffffffffffd3 16: 66 2e 0f 1f 84 00 00 cs nopw 0x0(%rax,%rax,1) 1d: 00 00 00 20: 0f 1f 00 nopl (%rax) 23: b8 31 00 00 00 mov $0x31,%eax 28: 0f 05 syscall 2a:* 48 3d 01 f0 ff ff cmp $0xffffffffffffff001,%rax <-- instrucción de captura 30: 73 01 jae 0x33 32: c3 ret 33: 48 8b 0d 09 8c 0c 00 mov 0xc8c09(%rip),%rcx # 0xc8c43 3a: f7 d8 neg %eax 3c: 64 89 01 mov %eax,%fs:(%rcx) 3f: 48 rex.W Código que comienza con la instrucción que falla =============================================== 0: 48 3d 01 f0 ff ff cmp $0xffffffffffffff001,%rax 6: 73 01 jae 0x9 8: c3 ret 9: 48 8b 0d 09 8c 0c 00 mov 0xc8c09(%rip),%rcx # 0xc8c19 10: f7 d8 neg %eax 12: 64 89 01 mov %eax,%fs:(%rcx) 15: 48 rex.W RSP: 002b:00007ffe2d0ad398 EFLAGS: 00000202 ORIG_RAX: 0000000000000031 RAX: ffffffffffffffda RBX: 00007ffe2d0ad3d0 RCX: 00007f59b934a1e7 RDX: 0000000000000001c RSI: 00007ffe2d0ad3d0 RDI: 0000000000000005 RBP: 00000000000000005 R08: 1999999999999999 R09: 0000000000000000 R10: 00007f59b9253298 R11: 000000000000 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ARM: reparar cacheflush con PAN Parece que la llamada al sistema cacheflush se rompió cuando se implementó PAN para LPAE. El acceso de usuario no estaba habilitado en torno a las instrucciones de mantenimiento de caché, lo que provocó que fallaran.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pmdomain: imx93-blk-ctrl: ruta de eliminación correcta La condición de comprobación debe ser 'i < bc->onecell_data.num_domains', no 'bc->onecell_data.num_domains', que hará que la búsqueda nunca finalice y provoque un pánico del kernel. También deshabilite el tiempo de ejecución para solucionar "imx93-blk-ctrl 4ac10000.system-controller: Unbalanced pm_runtime_enable!"

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: Controlar el error de asignación de dml para evitar un bloqueo [Por qué] En el caso de que una asignación de dml falle por cualquier motivo, los contextos dml del estado actual ya no serían válidos. Luego, las llamadas posteriores a dc_state_copy_internal realizarían una copia superficial de la memoria no válida y, si se liberara el nuevo estado, se produciría una doble liberación. [Cómo] Restablecer los punteros dml en new_state a NULL y evitar un puntero no válido (seleccionado de el commit bcafdc61529a48f6f06355d78eb41b3aeda5296c)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe/oa: Se corrige la advertencia "Falta protección de PM en tiempo de ejecución externo" Se corrige el siguiente drm_WARN: [953.586396] xe 0000:00:02.0: [drm] Falta protección de PM en tiempo de ejecución externo... <4> [953.587090] ? xe_pm_runtime_get_noresume+0x8d/0xa0 [xe] <4> [953.587208] guc_exec_queue_add_msg+0x28/0x130 [xe] <4> [953.587319] guc_exec_queue_fini+0x3a/0x40 [xe] <4> [953.587425] xe_exec_queue_destroy+0xb3/0xf0 [xe] <4> [953.587515] xe_oa_release+0x9c/0xc0 [xe] (seleccionado de el commit b107c63d2953907908fd0cafb0e543b3c3167b75)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nilfs2: fix null-ptr-deref in block_touch_buffer tracepoint Serie de parches "nilfs2: fix null-ptr-deref bugs on block tracepoints". Esta serie corrige errores de desreferencia de puntero nulo que ocurren al usar nilfs2 y dos puntos de seguimiento relacionados con bloques. Este parche (de 2): Se ha informado que al usar el punto de seguimiento "block:block_touch_buffer", touch_buffer() llamado desde __nilfs_get_folio_block() causa una desreferencia de puntero NULL o un error de protección general cuando KASAN está habilitado. Esto sucede porque, dado que el punto de seguimiento se agregó en touch_buffer(), hace referencia al miembro dev_t bh->b_bdev->bd_dev independientemente de si el cabezal del búfer tiene un puntero a una estructura block_device. En la implementación actual, la estructura block_device se establece después de que la función regresa al llamador. Aquí, touch_buffer() se utiliza para marcar el folio/página que posee el encabezado del búfer como accedido, pero el asistente de búsqueda común para folio/página utilizado por la función de llamada se optimizó para marcar el folio/página como accedido cuando se reimplementó hace mucho tiempo, eliminando la necesidad de llamar a touch_buffer() aquí en primer lugar. Por lo tanto, esto resuelve el problema al eliminar la llamada a touch_buffer() en sí.