Múltiples problemas de seguridad descubiertos en GNU Screen

 (openwall.com)
2 puntos por GN⁺ 2025-05-14 | 1 comentarios | Compartir por WhatsApp
  • Se descubrieron vulnerabilidades de seguridad graves en GNU Screen 5.0.0 y en instalaciones con setuid-root
  • Entre los principales problemas están la elevación local de privilegios a root, secuestro de TTY y creación de PTY escribibles por cualquiera
  • Varias distribuciones de Linux y UNIX están afectadas de forma parcial o total
  • Se ofrece un parche temporal y varias distribuciones requieren medidas prioritarias
  • El propio diseño de Screen con setuid-root presenta riesgos de seguridad fundamentales

1. Introducción

  • En julio de 2024, la revisión de seguridad comenzó cuando el mantenedor upstream de Screen solicitó una revisión de código
  • Antes no se habían encontrado problemas importantes, pero esta vez se descubrió una vulnerabilidad grave de elevación a root al usar Screen 5.0.0 con la configuración setuid-root
  • Además, se confirmaron varias vulnerabilidades de seguridad menores que también afectan a versiones anteriores (como 4.9.1)
  • El informe incluye conjuntos de parches por versión afectada (4.9.1, 5.0.0)
  • También abarca la configuración y versión de Screen por distribución, las vulnerabilidades principales, los riesgos de desarrollo relacionados con setuid-root, recomendaciones de endurecimiento de seguridad, problemas en el proceso de divulgación coordinada y una matriz de impacto

2. Resumen de configuración y versiones de Screen

  • En agosto de 2024 se lanzó Screen 5.0.0, incorporado en Arch Linux, Fedora 42 y NetBSD 10.1
  • La versión 5.0.0 incluye una gran cantidad de refactorización, y parte del código existe desde hace más de 10 años
  • Algunas vulnerabilidades fueron introducidas recientemente en 5.0.0, mientras que otras ya existían en versiones anteriores (como 4.9.1)
  • La mayoría de las distribuciones todavía usan 4.9.1
  • El modo multiusuario de Screen solo puede usarse si está instalado como setuid-root, y la complejidad del código aumenta considerablemente la superficie de ataque
  • Entre las distribuciones principales, Arch Linux, FreeBSD y NetBSD instalan Screen como setuid-root; Gentoo solo puede instalarlo así con la bandera USE “multiuser”

3. Detalle de los problemas de seguridad

3.a) Obtención de root local mediante logfile_reopen() (CVE-2025-23395)

  • Al ejecutar Screen 5.0.0 como setuid-root, la función logfile_reopen() crea archivos en rutas controladas por el usuario sin soltar privilegios
  • Un atacante puede crear archivos arbitrarios propiedad de root para registrar datos del terminal y luego explotarlos
  • También pueden aprovecharse archivos ya existentes; por ejemplo, insertando código en scripts de shell privilegiados
  • Arch Linux y NetBSD 5.0.0 son totalmente vulnerables, mientras que Fedora y ciertos entornos de Gentoo lo son de forma parcial
  • El parche se aplicó restaurando el manejo seguro de archivos, aunque el impacto concreto varía según la distribución

3.b) Secuestro de TTY al adjuntarse a sesiones multiusuario (CVE-2025-46802)

  • En la función Attach(), cuando está habilitada la bandera multiattach, los permisos del TTY cambian temporalmente a 0666
  • Durante ese proceso, una condición de carrera permite que un tercer usuario obtenga acceso de lectura y escritura a ese TTY
  • Existen riesgos de espionaje de entrada, manipulación de datos y robo de contraseñas
  • También hay rutas de código en las que los permisos del TTY no se restauran correctamente
  • El parche elimina la manipulación con chmod 666; algunos casos de reconexión podrían dejar de funcionar, aunque en la práctica ya no funcionaban antes

3.c) Vulnerabilidad en los permisos predeterminados de PTY (CVE-2025-46803)

  • En 5.0.0, los permisos predeterminados del PTY cambiaron de 0620 a 0622 (escribible por cualquiera)
  • Esto incrementa el riesgo potencial de seguridad, especialmente porque cualquier usuario puede escribir en PTY de otros
  • El cambio parece haber sido introducido por error, y el parche lo corrige restaurando el valor seguro por defecto (0620) en tiempo de compilación
  • Arch Linux y NetBSD son los principales afectados

3.d) Filtración de información sobre existencia de archivos mediante mensajes de error de socket (CVE-2025-46804)

  • Usando la variable de entorno SCREENDIR y mensajes de error, es posible comprobar con privilegios de root si existen archivos o directorios reales
  • Es una filtración de información menor, pero representa un riesgo en todos los entornos instalados como setuid-root

3.e) Condición de carrera TOCTOU al enviar señales (CVE-2025-46805)

  • Debido a la diferencia temporal entre las funciones CheckPid() y Kill(), existe el riesgo de enviar señales con privilegios de root a un PID distinto del previsto
  • Como principalmente solo se permiten señales como SIGCONT y SIGHUP, el impacto es limitado, pero puede causar denegación de servicio (DoS) o una afectación menor a la integridad

3.f) Desbordamiento al enviar comandos por uso incorrecto de strncpy()

  • En 5.0.0, el uso incorrecto de strncpy() provoca desbordamiento de búfer y fallos del programa
  • Si no se corrige adecuadamente, al enviar comandos se puede sobrescribir memoria después de MAXPATHLEN y llevar a una condición de indisponibilidad del servicio
  • No es un problema de seguridad, pero sí requiere una corrección rápida por estabilidad

4. Riesgos adicionales relacionados con la implementación setuid-root

  • En el modo multiusuario se confirmó una lógica deficiente para el manejo de UID de múltiples usuarios
  • La lógica para soltar privilegios en estado setuid-root no es completa
  • En sesiones creadas por root, no se logra una reducción efectiva de privilegios, lo que eleva el riesgo general

5. Recomendaciones generales de endurecimiento de seguridad

  • Durante el proceso de gran refactorización del código, se confirmó una ruptura de la lógica de seguridad existente
  • Dada la naturaleza de los binarios setuid-root, es necesario introducir suites de pruebas de seguridad y diseñar de forma conservadora todo el manejo de sistemas de archivos y variables de entorno
  • En particular, no se recomienda ejecutar todo Screen como setuid-root, y la función multiusuario debería limitarse solo a un modelo opt-in para grupos de confianza
  • Debe forzarse que las variables de entorno (como PAH) solo apunten a rutas confiables

6. Problemas en el proceso de coordinación para la divulgación de vulnerabilidades

  • El proceso de coordinación con upstream fue ineficiente, lo que provocó demoras en el desarrollo de parches y en la publicación
  • La limitada comprensión del código y capacidad técnica del upstream dificultó una respuesta estrecha y rápida
  • Finalmente, las distribuciones lideraron el desarrollo de parches y el informe se publicó según un calendario coordinado
  • También se constató una falta de capacidad de mantenimiento y gestión en el propio proyecto Screen

7. Matriz de impacto

  • Arch Linux (5.0.0, setuid-root): afectado por todas las vulnerabilidades 3.a, 3.b, 3.c, 3.d, 3.e y 3.f
  • Debian/Ubuntu y muchas otras distribuciones: 3.b (impacto parcial)
  • Fedora 42 (5.0.0, setgid-screen): afectado por 3.b (parcial) y 3.f
  • Gentoo (4.9.1, setgid-utmp): afectado por 3.b (parcial); con ebuild inestable + bandera USE multiuser, el impacto es el mismo que en 5.0.0
  • FreeBSD 14.2 (4.9.1, setuid-root): afectado por 3.b, 3.d y 3.e
  • NetBSD 10.1 (5.0.0, setuid-root): afectado por 3.a, 3.b, 3.c, 3.d, 3.e y 3.f
  • OpenBSD 7.7 (4.9.1): 3.b (impacto parcial)
  • openSUSE TW: 3.b (impacto parcial)

8. Cronología

  • 2024-07-01: upstream solicita revisión de código
  • 2025-01-08: inicio de la revisión
  • 2025-02-07: reporte privado de vulnerabilidades a upstream y solicitud de divulgación coordinada
  • 2025-02~04: discusión de parches y reajuste del calendario por problemas con el periodo de embargo
  • 2025-05-12: publicación de este informe y anuncio oficial

9. Enlaces de referencia

  • GNU Savannah [página del proyecto Screen]
  • openSUSE Bugzilla, parches relacionados, CVE de referencia, reportes de errores y enlaces a documentación

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-05-14
Opiniones en Hacker News
  • Screen tiene un modo multiusuario que permite que varios usuarios se conecten a la misma sesión; supongo que esta función es lo que hace posibles herramientas como tmate, y me pregunto si tmux tiene la misma vulnerabilidad
    • tmux usa sockets de dominio Unix; no entiendo por qué screen usó el enfoque setuid, no parece necesitar privilegios de root; según la explicación en el TFA, parece que los desarrolladores actuales de screen no entienden por completo la base de código y eligieron setuid-root porque era la forma más fácil de implementar la funcionalidad
    • Esta función es realmente excelente: en sesiones de entrenamiento, le doy a cada estudiante su propia cuenta de login en mi laptop y restrinjo su shell SSH con screen -x <ventana de cierto usuario>, para que cada estudiante solo pueda usar las ventanas permitidas por ese ACL de screen; luego voy mostrando con el proyector la pantalla de cada estudiante una por una, pero no sorprende que esté llena de agujeros de seguridad
    • Sí he usado el comando screen -x
  • En Debian, GNU screen no se instala con permisos setuid root
    • El paquete de Debian Stable (bookworm) es tan viejo que no está afectado por la vulnerabilidad 5.0.0; antes me molestaba que Debian fuera tan lento con las versiones de software, pero ahora uso versiones nuevas solo para algunas aplicaciones necesarias a través de fuentes de paquetes aparte, y para lo demás sigo usando versiones antiguas sin problema
    • En Gentoo pasa lo mismo, pero allí tiene SETGID configurado para el grupo utmp; no tengo claro qué implicaciones tiene eso
    • En Slackware 15, screen no tiene suid
    • En Fedora parece instalarse como setuid
  • Aquí está la versión renderizada de la entrada del blog: https://security.opensuse.org/2025/05/12/screen-security-issues.html
  • Le envié un correo al autor del artículo porque hay poca documentación sobre la función de registro en archivos log de GNU Screen; creo que GNU necesita un mejor sistema de seguimiento de issues; material relacionado: http://www.zoobab.com/screenrc
  • Ese comportamiento observado existe en Screen desde 2005; durante mucho tiempo se cubrió como antipatrón con herramientas como rkhunter, y estoy bastante seguro de que en los 90 screen ya era setuid root
  • Me sorprende que upstream se haya involucrado esta vez; hace unos 5 años me dio tristeza pensar que el desarrollo de GNU screen se había detenido por completo, y me pregunto si sigue siendo así; también me pregunto si hay una función para agregar nuevas ventanas a screen sin adjuntarse a la pantalla
    • Fue upstream quien pidió al equipo de SUSE que hiciera la revisión; si de verdad faltan manos de desarrollo y hoy está mal mantenido, sería una pena; aunque existan alternativas como tmux, mucha gente ha usado Screen durante años, y da lástima ese envejecimiento de las herramientas
    • Lo único en lo que se involucraron fue en distribuirlo como setuid-root; solo las distribuciones configuradas así son vulnerables, las demás no están afectadas; cuando el parche oficial tarda, las distribuciones lo parchean por su cuenta
    • No creo que sea necesariamente malo que el desarrollo de herramientas GNU se detenga —salvo correcciones de bugs—; puede ser una señal de que la funcionalidad ya está suficientemente completa
    • Es difícil comunicarse con upstream, así que no tengo información detallada sobre correcciones de bugs o releases; sí se pidió la revisión de seguridad, pero parece que es complicado contactarlos
    • En el software de código abierto hay un problema de inercia: aunque un programa llegue a su fin y aparezcan reemplazos, no siempre hay incentivos para cambiar de inmediato; por otro lado, también pasan casos donde alguien compra solo la marca y la cambia por algo totalmente distinto, como con Audacity; no hay una buena solución
  • Enlace a la versión renderizada: https://security.opensuse.org/2025/05/12/screen-security-issues.html
  • Me pregunto cuántos desarrolladores realmente usan por sí mismos todas estas herramientas populares de código abierto, y cuánto dinero circula en los campos donde se usan
  • Según recuerdo, tmux venía por defecto en OpenBSD desde la 4.6 y pasó por una auditoría, así que es una buena alternativa para quienes ponen más atención a la seguridad
    • Ver que se mencionaba screen me recordó cuando en el pasado me cambié a tmux y luego me confundía por no usar screen por costumbre
  • Me parece curioso que se mencione screen junto con setuid; una vez le hice chmod u+s a screen para resolver un problema raro, y se sentía extraño tener que hacer algo así; pero luego descubrí que screen tenía funciones que dependían de setuid y que algunos sistemas lo distribuían así por defecto; además, al ponerle u+s, screen leía el ~/.screenrc de root en lugar de mi ~/.screenrc (lo acepté como solución temporal); supongo que el soporte de setuid puede variar según cada build de screen
    • Así es como se supone que funciona setuid: al ponerle el bit especial al binario, significa que siempre debe ejecutarse con el usuario provisto