ssh-keysign-pwn - PoC de un 0-day de Linux que permite a usuarios sin privilegios leer archivos propiedad de root

 (github.com/0xdeadbeefnetwork)
1 puntos por GN⁺ 3 시간 전 | 1 comentarios | Compartir por WhatsApp
  • ssh-keysign-pwn es una PoC de una vulnerabilidad de Linux que permite a usuarios sin privilegios leer archivos propiedad de root, e indica que afecta a kernels anteriores a 31e62c2ebbfd
  • El bug central es que __ptrace_may_access() omite la verificación de dumpable cuando task->mm == NULL, y que do_exit() ejecuta exit_mm() antes que exit_files(), creando una ventana en la que los descriptores de archivo permanecen abiertos
  • En esa ventana, si el uid del llamador coincide con el del proceso objetivo, pidfd_getfd(2) tiene éxito, lo que permite obtener descriptores de archivo abiertos de un proceso que está terminando
  • sshkeysign_pwn obtiene /etc/ssh/ssh_host_{ecdsa,ed25519,rsa}_key, aprovechando el flujo en el que ssh-keysign.c abre claves con permisos 0600 y luego termina con EnableSSHKeysign=no antes de permanently_set_uid(), dejando un fd abierto
  • chage_pwn obtiene /etc/shadow, apuntando a la carrera de salida en el flujo donde chage -l <user> hace spw_open(O_RDONLY) y luego abandona completamente los privilegios con setreuid(ruid, ruid)
  • La ejecución consiste en usar make y luego ./sshkeysign_pwn para las claves del host, o ./chage_pwn root para imprimir el contenido de /etc/shadow en la salida estándar; se indica que suele acertar dentro de 100 a 2000 spawns
  • Los entornos confirmados son Raspberry Pi OS Bookworm 6.12.75, Debian 13, Ubuntu 22.04 / 24.04 / 26.04, Arch y CentOS 9
  • Como PoC controlada para el objetivo, vuln_target.c abre /etc/shadow y luego baja privilegios, mientras exploit_vuln_target.c muestra EPERM mientras sigue vivo y el robo del fd después de SIGKILL
  • La vulnerabilidad fue reportada por Qualys y Linus la corrigió el 2026-05-14; además, se indica que Jann Horn ya había señalado en octubre de 2020 la forma de robo de FD
  • El README presenta como entrada de NVD https://nvd.nist.gov/vuln/detail/CVE-2026-46333

Lecturas relacionadas

1 comentarios

 
GN⁺ 3 시간 전
Opiniones en Lobste.rs

  • Desactivar ptrace por sí solo no es suficiente. Es fácil confundirse por el mensaje del commit y el nombre de la función, pero ptrace_may_access se llama desde varias rutas y esta prueba de concepto (PoC) en realidad no usa ptrace
    No parece haber una mitigación ideal y, por ahora, sería algo como 1) quitar todos los bits de ejecución de /usr/lib64/misc/ssh-keysign solo para responder débilmente a esta PoC específica, o 2) bloquear pidfd_getfd con algo como eBPF o systemtap. Lo primero es más bien algo a considerar cuando no puedes parchear el kernel ni apagar el sistema y simplemente necesitas irte a dormir ya
    No revisé la PoC y, como siempre, hay que tener cuidado al ejecutar PoC aleatorias sacadas de internet
    El aviso de Qualys todavía no se ha publicado, y ya habían dicho que lamentaban mucho suspender la distribución en linux-distros debido a la política de seguridad del kernel de Linux. La situación se ha puesto más áspera porque los LLM ya pueden generar rápidamente una PoC a partir de commits de corrección que se ven sospechosos, y antes probablemente se podía esperar unos días
    Qualys realmente es un equipo excelente, así que da pena que no hayan podido tener el momento adecuado para presentar esto por su cuenta. Cuando lo publiquen, seguro será un gran aviso
    openssh solo es un objetivo conveniente para este ataque y no tiene la culpa; probablemente también se podrían elegir otros binarios setuid como objetivo

    • Según una actualización de Qualys, establecer /proc/sys/kernel/yama/ptrace_scope en 2 (admin-only attach) o 3 (no attach) bloquea todos los exploits conocidos. Aun así, en teoría podría haber otras formas de explotación
    • Como mitigación rápida, le pedí al LLM Opus que escribiera un script de systemtap para bloquear pidfd_getfd, y el resultado está aquí. Hay que ejecutarlo con stap -g block_pidfd_getfd.stp, y como con todo lo bajado de internet, hay que revisar el script antes de ejecutarlo
    • ¿Hay algún enlace al anuncio en linux-distros? No lo encuentro

  • Ojalá el kernel dejara de hacer su propia divulgación de 0-days al publicar commits de corrección en la rama principal. El commit incluso dice “Reported-by: Qualys”, así que claramente es una corrección de seguridad

    • La semana pasada hubo una gran discusión sobre este tema
      Greg K-H escribió que, como el equipo de seguridad del kernel no puede elegir quién recibe divulgación anticipada de correcciones de seguridad, al final nadie la recibe
    • Entonces, ¿qué se debería hacer en su lugar?

  • Esto no es un problema de ssh, es un problema de Linux. El título debería reflejar eso

    • Estoy de acuerdo en que el título induce a confusión, pero no se me ocurrió otra forma de ponerlo. Todavía se puede editar, así que agradecería sugerencias
    • Sí, pero al mismo tiempo, si ssh-keysign hubiera verificado EnableSSHKeysign=yes antes de abrir la clave privada del host, entonces los sistemas donde esa opción está desactivada, como por defecto, no habrían sido vulnerables al robo de la clave del host. Sorprende que ssh-keysign no revise esa opción primero

  • La prueba de concepto es agradablemente corta, y mis equipos también resultaron vulnerables
    Parece permitir acceso a descriptores de archivo abiertos por ejecutables setuid bajo ciertas condiciones. No veo por qué esto tendría que limitarse solo a lectura, y parece que podría adaptarse a una escalada local de privilegios (LPE) que no requiera crackear hashes
    Esta PoC en particular se puede romper con chmod -x /usr/lib/openssh/ssh-keysign /usr/bin/chage. Puede que haya que ajustar la ruta de ssh-keysign, y también se puede consultar la página del manual. Pero eso no arregla el problema central y parece probable que se pueda esquivar. Hasta donde sé, no hay otras mitigaciones
    Este problema fue corregido en ptrace: slightly saner 'get_dumpable()' logic, y por eso terminó haciéndose público. Fue hace apenas 10 horas
    También está el anuncio público de Qualys enviado a oss-security. Dicen que todavía no publican el aviso para darles tiempo a las distribuciones y a los usuarios de aplicar parches. Parece que va a ser un tema bastante interesante y, mientras tanto, se puede leer la explicación de Brad Spengler de grsecurity. Ese tuit parece haber sido el disparador de esta PoC

    • Probé ejecutar la PoC, pero no logré ganar la carrera. En cambio, el par exploit_vuln_target/vuln_target sí funcionó bien. No es nada bueno

  • En la práctica, esto parece afectar sistemas donde ya existe un usuario con una cuenta sin privilegios. O sea, si no hay un login válido, ¿es correcto que con esto no se puede lograr ejecución remota de código directamente en un servidor con SSH expuesto a internet?