Siga ZDNET: Agréganos como fuente preferida en Google.
Conclusiones clave de ZDNET
- Otro día, otro error de Linux.
- Ya hay un parche.
- Sin embargo, aún no está disponible en la mayoría de las distribuciones.
La última falla del kernel de Linux no tiene un nombre elegante; simplemente se llama «ssh‑keysign‑pwn». Es el cuarto agujero de seguridad local de alto perfil que afecta a Linux en tan sólo unas semanas. Éste permite a los usuarios comunes leer silenciosamente algunos de los archivos más confidenciales de un sistema, incluidas las claves privadas del host Secure Shell (SSH) y el archivo de contraseña oculta.
La vulnerabilidad recibe su apodo «ssh‑keysign‑pwn» de una de las principales rutas de explotación: el abuso del binario auxiliar ssh-keysign de OpenSSH. Keysign -keysign se utiliza para la autenticación basada en host y normalmente ejecuta setuid root, abriendo las claves de host SSH del sistema antes de perder privilegios para completar su trabajo.
Justo lo que necesitábamos. Otro error de Linux molesto y potencialmente peligroso.
El defecto explicado
Los investigadores de seguridad de la empresa de seguridad Qualys revelaron CVE‑2026‑46333, una vulnerabilidad de divulgación de información en la verificación de acceso ptrace del kernel de Linux. Qualys afirma que existe de una forma u otra desde hace unos seis años.
La falla se encuentra en la lógica __ptrace_may_access() que se ejecuta cuando los procesos salen. Bajo ciertas condiciones, el kernel omite las comprobaciones normales «volcables» una vez que un proceso ha eliminado su mapeo de memoria. Esto abre una breve ventana para que otro proceso robe sus descriptores de archivos.
Si bien ssh‑keysign‑pwn no entrega un shell raíz completo por sí solo, la capacidad de filtrar claves de host y hashes de contraseñas es un poderoso bloque de construcción para el movimiento lateral y la persistencia a largo plazo. Además, con claves de host SSH robadas, los atacantes pueden hacerse pasar por máquinas en relaciones de confianza basadas en host. Con acceso al directorio oculto de contraseñas, pueden intentar descifrar contraseñas sin conexión y reutilizar esas credenciales en todos los sistemas.
Justo lo que siempre necesitábamos. Un hack persistente que puede seguir robando claves y contraseñas.
En su parche, Linus Torvalds explicó que el problema existe porque «Tenemos un caso especial extraño: ptrace_may_access() usa ‘dumpable’ para verificar varias otras cosas completamente independientemente del MM (generalmente usando banderas explícitamente como PTRACE_MODE_READ_FSCREDS). Incluso para subprocesos que ya no tienen una VM (y tal vez nunca la tuvieron, como la mayoría de los subprocesos del kernel). No es para lo que se diseñó esta bandera, pero es lo que es».
Lo que eso significa para usted y para mí es que al combinar este error lógico con la llamada al sistema pidfd_getfd(2), los usuarios sin privilegios pueden acceder a procesos privilegiados que están a punto de cerrarse, tomar sus descriptores de archivos aún abiertos y luego leer archivos a los que normalmente sólo podría acceder el root.
Eso no sería gran cosa excepto que Qualys ha demostrado mediante un exploit de prueba de concepto (PoC) que el error se puede activar de forma fiable en la práctica, no sólo en teoría. La buena noticia es que la solución ya está disponible. El mantenedor estable de Linux, Greg Kroah-Hartman, ya ha implementado actualizaciones en múltiples ramas compatibles, incluidas nuevas versiones como 7.0.8, 6.18.31, 6.12.89, 6.6.139, 6.1.173, 5.15.207 y 5.10.256, todas las cuales incluyen la solución ssh-keysign-pwn.
lo que necesitas hacer
Querrá pasar a uno de estos núcleos lo antes posible. Este agujero afecta a todos los kernels de Linux lanzados antes del 14 de mayo de 2026. De lo contrario, como lo expresó un miembro cansado del equipo de Manjaro Linux: «No ejecutes tu PC si no la necesitas. Enciérrate y mira por encima del hombro». Bueno, ¡esa es sin duda una forma de afrontarlo!
Hasta que los núcleos parcheados estén ampliamente disponibles, los equipos de seguridad tienen algunas opciones de mitigación, pero cada una de ellas tiene sus contrapartidas.
Una solución rápida y sucia es reforzar las restricciones de Yama ptrace de Linux configurándolas con el comando:
sysctl kernel.yama.ptrace_scope=2.
Esto deshabilita ptrace para usuarios no root y bloquea el exploit, pero también interrumpe muchos flujos de trabajo de depuración y monitoreo. Esto no es ideal para los flujos de trabajo de los desarrolladores.
También puede reducir la exposición deshabilitando completamente la autenticación SSH basada en host y el asistente de firma de clave ssh en sistemas donde no son necesarios. Esto elimina una vía principal para robar claves de host. Sin embargo, esto también detiene SSH en seco, lo que para muchos sistemas Linux no es un inicio.
¿A mí? Estaré monitoreando mis sistemas y esperando que las distribuciones que uso todos los días (Linux Mint, Ubuntu, AlmaLinux, openSUSE y Rocky Linux) reciban parches para el final del fin de semana.
