Múltiples problemas de seguridad descubiertos en GNU Screen

• Una revisión de seguridad de GNU Screen confirmó, con foco en Screen 5.0.0 y las instalaciones setuid-root, escalamiento local de privilegios, secuestro de TTY, exposición de información, condiciones de carrera en el envío de señales y un bloqueo al enviar comandos
• El más grave, CVE-2025-23395, permite que logfile_reopen() procese rutas proporcionadas por el usuario con privilegios de root, lo que posibilita crear archivos propiedad de root en ubicaciones arbitrarias o agregar logs a archivos existentes
• También se revelaron como problemáticos comportamientos antiguos del modo multiusuario: Attach() cambia temporalmente la TTY a 0666, lo que habilita lectura y escritura por otros usuarios e inyección de entrada
• El riesgo por distribución varía según el método de instalación: Arch Linux y NetBSD 10.1 entregan Screen 5.0.0 como setuid-root, por lo que quedan muy expuestas a las principales vulnerabilidades
• La recomendación actual es no instalar Screen como setuid-root; la función multiusuario necesita opt-in basado en grupos de confianza, reducción de privilegios por defecto, elevación limitada de privilegios y limpieza de variables de entorno

---

Contexto de la divulgación y parches

• En julio de 2024, el mantenedor upstream de Screen solicitó una revisión de la base de código actual, y la revisión de seguridad real comenzó en enero de 2025
• La revisión encontró en la actualización principal Screen 5.0.0 un exploit local de root que afecta a distribuciones con setuid-root
• Además, se confirmaron problemas de menor gravedad, algunos de los cuales también afectan a Screen 4.9.1 y versiones anteriores, todavía presentes en muchas distribuciones
• Los problemas se compartieron en la lista de correo distros el 30 de abril de 2025 y se divulgaron públicamente el 12 de mayo de 2025
• El reporte adjuntó paquetes de parches por versión
  • screen-4.9.1-patches.tar.gz
  • screen-5.0.0-patches.tar.gz

Configuración de Screen y modo multiusuario

• Screen 5.0.0 se publicó upstream como release principal en agosto de 2024, y Arch Linux, Fedora 42 y NetBSD 10.1 ofrecen esta versión
• Muchas distribuciones Linux y UNIX seguían usando Screen 4.9.1 al momento de redactar el reporte
• El modo multiusuario de Screen permite, con las credenciales adecuadas, adjuntarse a sesiones de Screen propiedad de otros usuarios
  • Esta función solo está disponible cuando Screen está instalado con el bit setuid-root
  • Como el complejo código de Screen se ejecuta con privilegios de root, aumenta la superficie de ataque
• Entre los sistemas revisados, Arch Linux, FreeBSD y NetBSD instalan Screen como setuid-root
• En Gentoo Linux, el bit setuid-root se aplica si está configurada la USE flag "multiuser"
• Algunas distribuciones usan setgid en lugar de setuid
  • El valor predeterminado de Gentoo Linux es setgid-utmp, lo que permite a Screen crear registros de inicio de sesión en la base de datos utmp de todo el sistema
  • Fedora Linux usa setgid-screen, lo que permite a Screen colocar sockets en el directorio de todo el sistema /run/screen

CVE-2025-23395: exploit local de root en logfile_reopen()

• CVE-2025-23395 afecta a Screen 5.0.0 cuando se ejecuta con privilegios setuid-root
• La función logfile_reopen() no reduce privilegios al procesar rutas proporcionadas por el usuario
• Un usuario sin privilegios puede crear en ubicaciones arbitrarias archivos con las siguientes propiedades
  • Propietario: root
  • Grupo: el grupo real del usuario que invoca
  • Modo de archivo: 0644
• Los archivos ya existentes también pueden explotarse
  • Los datos escritos en el PTY de Screen se agregan a ese archivo
  • El modo y la propiedad del archivo existente no se modifican
• Screen reduce privilegios correctamente cuando abre por primera vez el archivo de log, pero aparece una posibilidad de escalamiento de privilegios en el momento en que decide que debe volver a abrir el archivo de log
• En la comprobación stolen_logfile(), si el link count del archivo de log original llega a 0 o su tamaño cambia de forma inesperada, se llama a logfile_reopen()
• Un usuario sin privilegios puede provocar intencionalmente esta condición
• El patch 0001 para Screen 5.0.0 reintroduce el manejo seguro de archivos durante la reapertura del archivo de log
• Este problema se originó cuando se eliminó lf_secreopen() en el antiguo commit 441bca708bd, y ese cambio se incluyó en el release 5.0.0

CVE-2025-46802: secuestro de TTY durante attach a sesiones multiusuario

• CVE-2025-46802 ocurre en la función Attach() cuando está configurado el flag multiattach
• Al hacer attach a una sesión multiusuario, Screen cambia con chmod() el modo de la TTY actual a 0666
• La ruta de la TTY se valida con condiciones como que esté bajo /dev y isatty(), por lo que este comportamiento por sí solo no se convierte en un exploit local de root separado
• El problema es que, mientras los permisos de la TTY se relajan temporalmente, se genera una condición de carrera que permite a otros usuarios leer y escribir en esa TTY
• En una prueba simple basada en la API inotify de Linux, un script de Python pudo abrir la TTY afectada cada dos o tres intentos
• Un atacante puede hacer lo siguiente
  • Interceptar datos ingresados en la TTY
  • Inyectar datos en la TTY
  • Engañar al usuario para que ingrese una contraseña
  • Inyectar secuencias de control para confundir a la víctima o apuntar a problemas relacionados en emuladores de terminal
• En algunas rutas de return de Attach(), el modo original de la TTY no se restaura
  • Ejemplo: cuando no se encontró la sesión objetivo y el argumento "quiet" está configurado
• El parche elimina el chmod() temporal
  • patch 0001 para Screen 4.9.1
  • patch 0004 para Screen 5.0.0
• Poco antes de la divulgación pública se confirmó que este parche podía romper algunos casos de uso de reattach, pero se verificó que esos casos ya estaban rotos también en Screen 4.9.1
• Este problema existía en versiones de Screen al menos desde 2005 y afecta a distribuciones Linux y BSD que ofrecen soporte multiusuario con setuid-root
• Incluso sin setuid-root, en teoría puede afectar porque el usuario tiene permiso para cambiar el modo de su propia TTY, pero Screen no continúa hacia sesiones de otros usuarios sin privilegios de root

CVE-2025-46803: valor predeterminado de PTY world-writable en Screen 5.0.0

• CVE-2025-46803 es el problema por el cual el modo predeterminado de los PTY asignados por Screen cambió de 0620 a 0622 en Screen 5.0.0
• Con este valor predeterminado, cualquiera en el sistema puede escribir en el PTY de Screen
• Desde el punto de vista de seguridad, genera un problema similar a CVE-2025-46802, pero sin el componente de filtración de información
• En Screen 4.9.1, el valor predeterminado a nivel de código era 0622, pero se aplicaba el valor predeterminado 0620 de la configuración autotools, por lo que se usaba un valor seguro
• En Screen 5.0.0, configure.ac fue reescrito, desapareció el valor predeterminado 0620 a nivel de autoconf, y luego el switch de configure pty-mode se reintrodujo con 0622 como valor predeterminado
• No se encontraron notas de release de 5.0.0 y solo había algunas entradas del ChangeLog, por lo que el cambio del modo PTY predeterminado no parece haber sido una decisión intencional
• El patch 0002 para Screen 5.0.0 restaura en configure.ac el modo PTY predeterminado seguro
  • Para aplicar el cambio es necesario ejecutar autoreconf
• Se recomienda a los empaquetadores pasar explícitamente el switch de configure --with-pty-mode=0620
• Gentoo Linux y Fedora Linux pasan explícitamente el --with-pty-mode seguro
• Arch Linux y NetBSD no pasan ese switch, por lo que se aplica el nuevo valor predeterminado y quedan vulnerables

CVE-2025-46804: exposición de existencia de archivos mediante mensajes de error de rutas de socket

• CVE-2025-46804 es una filtración menor de información que ocurre cuando Screen se ejecuta con privilegios setuid-root
• Se confirmó tanto en versiones antiguas de Screen como en 5.0.0
• Screen verifica SocketPath con privilegios de root y expone en mensajes de error información de rutas que un usuario sin privilegios normalmente no podría conocer
• Usando la variable de entorno SCREENDIR, se puede inferir la siguiente información
  • Si /root/.lesshst es un archivo regular
  • Si existe el directorio /root/.cache
  • Si la ruta /root/test no existe
• El parche cambia el comportamiento para que, en instalaciones setuid-root, solo se muestre un mensaje de error genérico cuando la ruta objetivo no está controlada por el UID real del proceso
  • patch 0002 para Screen 4.9.1
  • patch 0005 para Screen 5.0.0
• Todas las distribuciones revisadas están afectadas

CVE-2025-46805: condición de carrera TOCTOU en el envío de señales

• CVE-2025-46805 es una condición de carrera TOCTOU que ocurre al enviar señales a un PID proporcionado por el usuario en un contexto setuid-root
• CheckPid() baja privilegios al ID de usuario real y luego comprueba si el kernel permite enviar una señal al PID objetivo
• La señal real se envía después mediante Kill(), momento en el que pueden usarse privilegios de root
• Entre la comprobación y el envío real, el PID previamente comprobado puede ser reemplazado por otro privileged process
• También podría engañarse a un proceso daemon privilegiado de Screen para que se envíe una señal a sí mismo
• Actualmente solo pueden enviarse SIGCONT y SIGHUP, por lo que es probable que el impacto quede en el ámbito de una denegación de servicio local o una infracción menor de integridad
• Este problema se originó en una corrección incompleta de CVE-2023-24626
  • Antes de esa corrección, estas señales podían enviarse a procesos arbitrarios sin condición de carrera
• El parche cambia el envío real de la señal para que también se haga con los privilegios del UID real, igual que CheckPid()
  • patch 0003 para Screen 4.9.1
  • patch 0006 para Screen 5.0.0
• Todas las distribuciones revisadas están afectadas

Bloqueo al enviar comandos por el uso de strncpy() en Screen 5.0.0

• Screen 5.0.0 tiene un problema relacionado con strncpy() que no se considera un issue de seguridad, pero que debe corregirse con prioridad
• En el commit 0dc67256, varias llamadas a strcpy() fueron reemplazadas por strncpy()
• strncpy() no es una función para manejo seguro de strings, sino una función que rellena con ceros un búfer de longitud fija; por eso, incluso después del primer byte \0, escribe ceros hasta el final del búfer de destino
• En el bucle de procesamiento de argumentos de línea de comandos de attacher.c, se pasa MAXPATHLEN como tamaño de destino incluso después de la primera iteración
• Como el puntero p ya fue incrementado pero se sigue pasando el mismo tamaño, las llamadas posteriores a strncpy() escriben bytes \0 más allá del final del búfer
• En Arch Linux, al enviar más de un argumento de comando a una sesión de Screen en ejecución, se observó el siguiente error en builds con _FORTIFY_SOURCE habilitado
  • *** buffer overflow detected***: terminated
  • Aborted (core dumped)
• Sin _FORTIFY_SOURCE, puede no haber un error visible, y puede que tampoco aparezca un error con -fsanitize=address
• El llamador puede sobrescribir con ceros los MAXPATHLEN bytes posteriores al búfer cmd, pero como después hay un búfer writeback[MAXPATHLEN] del mismo tamaño, se considera que no habría una forma favorable para que un atacante lo explote
• El patch 0003 para Screen 5.0.0 cambia strncpy() por snprintf() y pasa correctamente el tamaño restante del búfer de destino
• Todas las distribuciones que ofrecen Screen 5.0.0 están afectadas

Alcance del impacto por distribución

Sistema	Versión de Screen	Privilegios especiales	Impacto
Arch Linux	5.0.0	setuid-root	3.a, 3.b, 3.c, 3.d, 3.e, 3.f
Debian 12.10	4.9.0	ninguno	parte de 3.b
Ubuntu 24.04.2	4.9.1	ninguno	parte de 3.b
Fedora 42	5.0.0	setgid-screen	parte de 3.b, 3.f
Gentoo	4.9.1	setgid-utmp, setuid-root si está configurada la USE flag multiuser	parte de 3.b
openSUSE TW	4.9.1	ninguno	parte de 3.b
FreeBSD 14.2	4.9.1	setuid-root	3.b, 3.d, 3.e
NetBSD 10.1	5.0.0	setuid-root	3.a, 3.b, 3.c, 3.d, 3.e, 3.f
OpenBSD 7.7	4.9.1	ninguno	parte de 3.b

Preocupaciones y recomendaciones sobre el diseño setuid-root

• En el modo multiusuario de Screen intervienen tres UID
  • effective UID 0 para privileged operation
  • UID real del usuario que creó la sesión
  • UID real del usuario que se adjunta a la sesión
• La estructura actual del código de Screen parece dificultar reflejar correctamente esta distinción
• Una sesión multiusuario de Screen creada por root “reduce privilegios” al UID real del creador de la sesión, que es 0, por lo que en la práctica no hay reducción de privilegios
• Durante la refactorización de Screen 5.0.0 se rompió lógica de seguridad que existía desde hacía mucho tiempo, y como resultado surgieron CVE-2025-23395 y CVE-2025-46803
• Antes de más refactorizaciones, hace falta una suite de pruebas que pueda verificar las propiedades de seguridad de la implementación
• Los desarrolladores que trabajan con binarios setuid-root deben entender los riesgos de esa área
• Screen sigue ejecutándose con privilegios elevados y solo reduce privilegios de forma selectiva en operaciones que considera riesgosas
• Un programa setuid-root robusto debería bajar privilegios por defecto y elevarlos solo en las operaciones que realmente necesitan privilegios elevados
• En un contexto setuid-root, se necesita lógica para eliminar todas las variables de entorno salvo las permitidas explícitamente
• Variables de entorno como PATH deben limpiarse para que solo apunten a directorios de sistema confiables
• Actualmente se recomienda no instalar como setuid-root ni Screen 5.0.0 ni la serie 4.9 anterior
• Como alternativa, la función multiusuario podría ofrecerse mediante opt-in y permitir que solo miembros de un grupo confiable ejecuten la versión multiusuario de Screen

Proceso de coordinación de la divulgación y estado upstream

• En febrero de 2025, los problemas se reportaron de forma privada al upstream de Screen y se propuso una divulgación coordinada
• Upstream mostró interés en mantener los problemas en privado para corregir los bugs antes de la publicación, e indicó que necesitaría entre 1 y 2 meses
• Alrededor de un mes después comenzó actividad del lado de upstream y discusión de parches, pero la discusión no fue suficientemente productiva
• Hasta que se acercó el periodo máximo de embargo de 90 días no hubo más comunicación, y mientras tanto distribuciones como NetBSD actualizaron a Screen 5.0.0, quedando plenamente afectadas por CVE-2025-23395
• Se concluyó que upstream no estaba lo bastante familiarizado con la base de código de Screen y no entendía completamente los problemas de seguridad reportados
• Upstream quería una divulgación más temprana aunque algunos problemas seguían sin resolverse, por lo que el borrador se envió rápidamente a la lista de correo distros
• Luego, SUSE desarrolló directamente las correcciones faltantes, y también ajustó y documentó los parches discutidos en forma de borrador con upstream
• Se estima que, con capacidad upstream dedicada, el proceso de divulgación coordinada podría haberse completado en unas 2 semanas
• Screen upstream parece sufrir falta de personal y experiencia, lo que preocupa especialmente por tratarse de una utilidad de código abierto ampliamente usada

Cronología principal

• 2024-07-01: se recibió la solicitud de revisión de upstream
• 2025-01-08: comenzó el trabajo de revisión de seguridad
• 2025-02-07: reporte privado a Screen upstream y propuesta de divulgación coordinada
• 2025-02-11: creación de un bug privado en el bug tracker de GNU Savannah
• 2025-04-30: decisión de asignación de CVE y borrador compartido en la lista de correo distros
• 2025-05-07: versiones finales de los parches para Screen 4.9.1 y 5.0.0 compartidas con la lista de correo distros y upstream
• 2025-05-12: el reporte se publicó en el blog y en la lista de correo oss-security

[GN⁺]

Opiniones en Hacker News

• No sabía que Screen tenía este modo multiusuario, pero probablemente sea la razón por la que herramientas como tmate son posibles.
  Con las credenciales adecuadas, otro usuario puede conectarse a una sesión de Screen propiedad de otro, y dicen que esta función solo es posible cuando Screen está instalado como setuid-root.
  Por eso me pregunto si tmux también se ve afectado por el mismo tipo de vulnerabilidad.

  • tmux no aplica porque usa sockets de dominio Unix.
    No sé por qué screen eligió aquí el enfoque setuid, y no parece necesitar privilegios de root en absoluto.
    Más abajo en el artículo aparece una explicación plausible de que los desarrolladores actuales de screen no están del todo familiarizados con la base de código; si es así, puede que setuid-root haya sido la forma más fácil de hacer funcionar la característica.
  • Es una función bastante excelente.
    En sesiones de capacitación, le daba a cada estudiante una cuenta para iniciar sesión en mi laptop, restringía el shell SSH a screen -x y, con las listas de control de acceso de screen, hacía que cada estudiante solo pudiera usar su propia ventana.
    Durante la práctica, yo, como propietario de screen, podía proyectar la pantalla de cada estudiante para que toda la clase viera el resultado.
    No me sorprendería que tuviera muchos agujeros de seguridad.
  • Sí, screen -x.

• En Debian, GNU screen no se instala con privilegios setuid-root.

  • El paquete de Debian Stable, es decir bookworm, es tan viejo que no se ve afectado por la vulnerabilidad de 5.0.0.
    Antes me molestaba que Debian siempre estuviera atrasado en versiones de software, pero ahora uso otras fuentes de paquetes solo para algunas apps en las que no quiero depender de software realmente antiguo, como los navegadores, y para el resto me va bien con paquetes viejos.
  • En Slackware 15, /usr/bin/screen apunta a screen-4.9.0, y el ejecutable tampoco es suid.
  • En Gentoo pasa lo mismo.
    Aunque en Gentoo tiene SETGID para el grupo utmp, pero no sé bien qué impacto tiene eso.
  • En Fedora parece ser setuid-root.

• El artículo renderizado está aquí: https://security.opensuse.org/2025/05/12/screen-security-iss...

• Una vez le mandé un email al autor de GNU Screen diciendo que la función de registro en archivo no estaba bien documentada: http://www.zoobab.com/screenrc
  GNU necesita un mejor sistema de seguimiento de issues.

  • Hubo una sesión de preguntas y respuestas con el autor de Tmux, y ya hace unos 16 años se quejaba de la falta de documentación.
    https://undeadly.org/cgi?action=article&sid=20090712190402
  • Está documentado en detalle en el manual de GNU screen: https://www.gnu.org/software/screen/manual/screen.html#Log
  • Bastantes proyectos antiguos tienen el problema de que los issues quedan enterrados en las profundidades interminables de listas de correo sin indexar.
    Es válido criticar a Discord por volver inaccesible este tipo de información, pero el IRC que algunos proyectos todavía usan en la práctica es el doble de peor.
    Ojalá estos proyectos se mudaran a lugares como Gitea, Forgejo, Codeberg, GitLab o GitHub para reunir el contenido relacionado y asegurar su descubribilidad.

• Zellij es una alternativa moderna bastante buena a screen y tmux, tiene valores por defecto excelentes y una UI diseñada para que sea fácil descubrir sus funciones.
  Se lo recomiendo a quienes sienten que la relación esfuerzo/beneficio de los multiplexores de terminal es dudosa.
  https://zellij.dev
  https://github.com/zellij-org/zellij

  • Lo probé hace unos años y era bastante pulido.
    Pero, en comparación con tmux, la latencia era notable, y sigo usando tmux.
    En ese momento ya estaba usando una conexión con latencia, así que tal vez yo estaba algo sensible al tema.
  • La última vez que vi Zellij parecía un gran proyecto nuevo en el ecosistema de multiplexores, pero no soportaba un mecanismo de copiar/pegar basado puramente en teclado.
    Uso muchísimo esa función, así que no puedo usarlo sin ella, y hasta que la agreguen no me queda otra que usar tmux.
  • Está bueno, pero realmente me gusta screen y sus comandos ya están grabados en mi memoria muscular.
    Lo he usado por más de 20 años.

• Me sorprende que upstream haya participado en esto.
  Hace unos 5 años llegué tristemente a la conclusión de que el desarrollo de GNU screen se había detenido por completo, y me pregunto si acaso ya no es así.
  No sé si screen todavía tiene la función de agregar una ventana nueva sin conectarse a una screen existente.

  • Upstream le pidió al equipo de SUSE que lo revisara.
    Parece que les falta personal de desarrollo, y quizá upstream no tenga la experiencia necesaria para mantenerlo bien.
    Si es cierto, es triste. Sé que existen tmux y otras alternativas, pero mucha gente ha usado Screen durante muchísimo tiempo, y da pena ver cómo una herramienta se va pudriendo lentamente.
  • Dice que, por la dificultad de comunicarse con upstream, actualmente no tienen información detallada sobre las correcciones de bugs y los lanzamientos que hicieron ellos.
    Aunque pidieron una revisión de seguridad, parece que fue difícil mantener el contacto, y no conozco toda la situación.
  • La participación, si se le puede llamar así, fue distribuirlo como setuid-root.
    Las distribuciones configuradas así son vulnerables, y las que no, no lo son.
    Yo lo veo como una participación muy superficial. Si upstream es demasiado lento, la distribución parchea.
  • Que el desarrollo de una herramienta GNU se detenga no necesariamente es algo triste. Claro, dejando de lado las correcciones de bugs.
    Básicamente puede tomarse como señal de que es una herramienta terminada.
  • En el open source hay un problema de inercia cuando un software llega a su fin y se crea otro para reemplazarlo.
    No hay un incentivo inmediato para cambiarse, porque no es una actualización sino una migración.
    Por otro lado, también es malo que alguien compre la marca de un software existente y lo transforme en algo completamente distinto, como pasó con Audacity.
    Así que no parece haber una buena solución.

• Versión renderizada: https://security.opensuse.org/2025/05/12/screen-security-iss...

• Si no recuerdo mal, tmux entró en el sistema base desde OpenBSD 4.6 y es una herramienta que fue, o ha sido, auditada.
  Es buena para quienes quieren una alternativa un poco más segura.

  • Ver que screen reaparece me recuerda cuando en su momento me pasé a tmux y me olvidé de screen.

• El comportamiento observado estaba en versiones de Screen al menos desde 2005, ya era un antipatrón desde hace todo ese tiempo, y herramientas como rkhunter también lo trataban.
  Aun así, creo que screen ya era setuid root en los 90.

• ¿Cuántos desarrolladores mantienen realmente las herramientas open source más populares?
  ¿Cuánto dinero hay en las industrias que usan esas herramientas?