Una nueva vulnerabilidad del núcleo de Linux, denominada «ssh-keysign-pwn», permite obtener acceso de root en las principales distribuciones

La versión resumida

¿Qué: Una vulnerabilidad de escalada de privilegios locales en Linux en __ptrace_may_access(), conocida informalmente como «ssh-keysign-pwn» (o «chage_pwn», en referencia al PoC del titular). En el momento de la publicación aún no se le ha asignado ningún CVE.

Repercusión: A prueba de concepto pública consigue elevar de forma fiable los privilegios de un usuario local sin privilegios a root aprovechando una vulnerabilidad en los binarios SUID a través de esa ventana: chage filtrarse /etc/shadow, ssh-keysign filtrar claves privadas de hosts SSH.

Estado: En corrección en la fase inicial (confirmar 31e62c2) salió al mercado en la misma época que el Comunicado público sobre seguridad del software libre. Aún no se ha asignado ningún CVE, el aviso de Qualys aún no se ha publicado y todavía no hay puntuación CVSS. KernelCare ha lanzado parches que no requieren reinicio para Ubuntu 22.04 (Jammy), Debian 11 (en ePortal) y la familia EL9 (en los repositorios test y main), RHEL 8/Rocky Linux 8 (en canal de pruebas).

Gravedad: Vía de ataque local, no requiere privilegios, no requiere interacción del usuario, no requiere configuración especial. El PoC público funciona de forma inmediata en Debian 11/12/13, Ubuntu 22.04/24.04/26.04, Arch, Raspberry Pi OS Bookworm y las familias EL9 y EL10. EL8 y Ubuntu 20.04 son vulnerables, pero necesitan un PoC adaptado. EL7 con el kernel 3.10 no se ve afectado.

Por qué es importante: dado que la vulnerabilidad afecta a archivos binarios SUID habituales y no requiere privilegios ni la intervención del usuario, los sistemas Linux multiusuario vulnerables deben considerarse en riesgo inmediato.

Haz esto ahora mismo: Aprieta Yama ptrace_scope en los servidores (un ajuste de sysctl, reversible). KernelCare Los clientes deben estar atentos al lanzamiento de la versión de prueba. A continuación se incluyen los comandos de mitigación y las instrucciones para la aplicación de parches sin necesidad de reiniciar el sistema.

La versión larga

Esta mañana ha aparecido en GitHub un exploit de nivel root del núcleo de Linux sin número CVE, sin aviso por parte del investigador que descubrió la vulnerabilidad y con una prueba de concepto pública que funciona en un sistema Debian o Ubuntu sin modificar. El fallo se encuentra en __ptrace_may_access(). La corrección se incorporó al código fuente original en ese mismo plazo; una buena noticia, salvo que nadie fuera de los equipos del núcleo de la distribución podrá disponer de ella hasta dentro de unos días.

A continuación se detallan los pormenores de la cronología. Jann Horn propuso una solución equivalente para este error en 2020. No se incorporó al código. La causa principal permaneció en todas las ramas estables del núcleo durante cinco años, hasta que un investigador de Qualys la redescubrió y otro investigador publicó dos exploits funcionales en el repositorio ssh-keysign-pwn pocas horas después de la divulgación en el código fuente original.

El parche de KernelCare que no requiere reinicio está en fase de desarrollo. Hasta que esté disponible, hay un parámetro sysctl que bloquea por completo la demostración de concepto pública. A continuación te explicamos qué está pasando y qué puedes hacer hoy mismo.

Cómo funciona la vulnerabilidad

Una refactorización de 2017 de __ptrace_may_access() (confirmar bfedb589, v4.10-rc1) invirtió silenciosamente la comprobación de acceso cuando una tarea mm es NULL. El código anterior a la refactorización denegaba el acceso en ese estado. El código refactorizado pasa por alto esa condición y permite el acceso.

Al salir del proceso, hay un intervalo de tiempo de la orden de microsegundos en el que task->mm ya se ha borrado, pero los descriptores de archivo de la tarea siguen activos. El PoC público ejecuta un proceso SUID en ese intervalo de tiempo utilizando pidfd_open y pidfd_getfd, con dos objetivos ya definidos en el repositorio: chage filtrarse /etc/shadow, y ssh-keysign filtrar claves privadas de hosts SSH. La tasa de aciertos comunicada es de entre 100 y 2.000 procesos generados por cada intento exitoso.

Jann Horn propuso una solución equivalente en 2020 (v1, v2). No se incorporó al código y el error siguió sin resolverse.

¿A quién afecta?

La regresión se ha incorporado a la serie estable v4.4.40, por lo que, de forma predeterminada, afecta a prácticamente todos los núcleos de distribuciones modernas que no sean EL7. Tres grupos:

La demostración de concepto pública funciona nada más instalarla:

• Debian 11, 12, 13
• Ubuntu 22.04, 24.04, 26.04
• Arch Linux (actual)
• Raspberry Pi OS Bookworm
• CentOS Stream 9, AlmaLinux 9, RHEL 9, Oracle Linux 9, Rocky Linux 9
• AlmaLinux 10, RHEL 10

Es vulnerable, pero el PoC necesita adaptarse:

• Familia EL8 (RHEL 8, AlmaLinux 8, Rocky 8, Oracle Linux 8)
• Ubuntu 20.04

No se ve afectado:

• La familia EL7 en el núcleo 3.10: es anterior a la regresión de 2017

Actúa ya

Aprieta Yama ptrace_scope. El exploit aprovecha el fallo a través de pidfd_getfd(). pidfd_getfd() llamadas ptrace_may_access(…, PTRACE_MODE_ATTACH_REALCREDS), que ejecuta el gancho LSM al final de __ptrace_may_access. Un Yama deniega el error, independientemente de que se produzca la caída a mm-NULL defectuosa.

El común ptrace_scope=1 La configuración predeterminada (la que viene de serie en Debian/Ubuntu) NO es suficiente. Bajo scope=1, se permite la conexión de proceso padre a hijo. El atacante genera él mismo el proceso SUID, por lo que son el elemento principal. Debes desplazarte a scope=2 o scope=3.

Recomendado: ptrace_scope=2 (Adición exclusiva para administradores, totalmente reversible en tiempo de ejecución):

sudo sysctl -w kernel.yama.ptrace_scope=2

Revertir después de instalar el parche sin reinicio:

sudo rm /etc/sysctl.d/99-ssh-keysign-pwn.conf

Más fuerte: ptrace_scope=3 (sin afectación para nadie, irreversible sin reiniciar el sistema):

sudo sysctl -w kernel.yama.ptrace_scope=3

scope=3 es un cambio irreversible hasta que se reinicie el sistema: el núcleo rechaza cualquier intento posterior de reducirlo (sysctl -w kernel.yama.ptrace_scope=2 devoluciones EINVAL). Elige esta opción solo si estás dispuesto a reiniciar el sistema para revertir los cambios y si el acceso de depuración como root (gdb -p, strace -p (como root) no forma parte de tus operaciones habituales.

Compatibilidad

• scope=2 interrumpe sin privilegios gdb -p / strace -p / perf trace --pid y flujos de depuración de contenedores root conserva el enlace, por lo que la resolución de problemas por parte del administrador sigue funcionando.
• scope=3 impide el acceso a la depuración para todos los usuarios, incluido root.

Parche sin reinicio de KernelCare

KernelCare ha publicado parches que no requieren reinicio para Ubuntu 22.04 (Jammy), Debian 11 (en ePortal), la familia EL9 (en los repositorios «test» y «main»), y RHEL 8/Rocky Linux 8 (en el repositorio «test»).

Una vez que se publique en el feed de prueba:

kcarectl --update --prefix test

Una vez validado, el parche se instalará en la próxima ejecución programada, o bien puedes descargarlo cuando lo necesites:

kcarectl --update

A qué hay que estar atento a medida que se desarrolle la situación

• Asignación de CVE: (ninguna en el momento de redactar este documento)
• El propio aviso de Qualys, que probablemente incluirá una descripción técnica más detallada
• Actualizaciones del núcleo de las distribuciones de Debian, Ubuntu y los proveedores de EL9/10
• Nuevas modificaciones en el repositorio público ssh-keysign-pwn: es poco probable que los dos objetivos actuales sean los únicos viables

Actualizaremos esta publicación cuando se publique el CVE y cuando el parche de KernelCare pase de la fase de pruebas a la estable. Si utilizas KernelCare, el parche se instalará automáticamente, por lo que no es necesario que hagas nada.

Si aún no eres usuario de KernelCare, este es un buen momento para descubrir cómo los parches sin reinicio pueden proteger los sistemas Linux críticos sin necesidad de ventanas de mantenimiento de emergencia ni tiempos de inactividad.

Más información sobre KernelCare aquí →