Plusieurs problèmes de sécurité découverts dans GNU Screen

 (openwall.com)
2 points par GN⁺ 2025-05-14 | 1 commentaires | Partager sur WhatsApp
  • De graves vulnérabilités de sécurité ont été découvertes dans GNU Screen 5.0.0 et dans les installations en setuid-root
  • Les principaux problèmes incluent une élévation locale de privilèges root, le détournement de TTY et la création de PTY accessibles en écriture à tous
  • De nombreuses distributions Linux et UNIX sont affectées en partie ou en totalité
  • Des correctifs temporaires sont fournis et une action prioritaire est nécessaire dans plusieurs distributions
  • La conception même de Screen en setuid-root présente des risques de sécurité fondamentaux

1. Introduction

  • En juillet 2024, l’examen de sécurité a commencé lorsque le mainteneur upstream de Screen a demandé une revue de code
  • Aucun problème particulier n’avait été trouvé auparavant, mais cette fois une grave vulnérabilité d’élévation de privilèges root a été découverte dans Screen 5.0.0 lorsqu’il est configuré en setuid-root
  • En complément, plusieurs vulnérabilités de moindre gravité affectant aussi les versions antérieures (4.9.1, etc.) ont été identifiées
  • Le rapport inclut des jeux de correctifs par version (4.9.1, 5.0.0)
  • Il couvre notamment la configuration et la version de Screen selon les distributions, les principales vulnérabilités, les risques de développement liés au setuid-root, les recommandations de durcissement, les problèmes dans le processus de coordination de publication et une matrice d’impact

2. Aperçu de la configuration et des versions de Screen

  • En août 2024, Screen 5.0.0 a été publié et intégré dans Arch Linux, Fedora 42 et NetBSD 10.1
  • La version 5.0.0 comprend de nombreux refactorings, dont certains portent sur du code présent depuis plus de dix ans
  • Certaines vulnérabilités ont été introduites dans 5.0.0, tandis que d’autres existaient déjà dans les versions précédentes (4.9.1, etc.)
  • La plupart des distributions utilisent encore 4.9.1
  • Le mode multi-utilisateur de Screen n’est disponible que lorsqu’il est installé en setuid-root, ce qui augmente fortement la surface d’attaque en raison de la complexité du code
  • Parmi les principales distributions, Arch Linux, FreeBSD et NetBSD installent Screen en setuid-root ; Gentoo ne permet une installation en setuid-root qu’avec le drapeau USE « multiuser »

3. Détails des problèmes de sécurité

3.a) Obtention locale des privilèges root via logfile_reopen() (CVE-2025-23395)

  • Lors de l’exécution de la version setuid-root de Screen 5.0.0, la fonction logfile_reopen() crée un fichier à partir d’un chemin fourni par l’utilisateur sans abandonner ses privilèges
  • Un attaquant peut créer un fichier arbitraire appartenant à root afin d’y enregistrer des données de terminal puis en abuser
  • Des fichiers déjà existants peuvent aussi être exploités, par exemple via l’injection de code dans un script shell privilégié
  • Arch Linux et NetBSD 5.0.0 sont entièrement vulnérables, tandis que Fedora et certains environnements Gentoo sont partiellement vulnérables
  • Le correctif a été appliqué en restaurant une gestion sécurisée des fichiers, avec des impacts spécifiques selon les distributions

3.b) Détournement de TTY lors de l’attachement à une session multi-utilisateur (CVE-2025-46802)

  • Dans la fonction Attach(), lorsque l’option multiattach est activée, les permissions du TTY passent temporairement à 0666
  • Pendant cette opération, une condition de concurrence (race condition) permet à un troisième utilisateur d’obtenir un accès en lecture/écriture à ce TTY
  • Les risques incluent l’écoute des données d’entrée, leur modification et le vol de mots de passe
  • Il existe également des chemins de code où les permissions du TTY ne sont pas restaurées
  • Le correctif supprime la modification en chmod 666 ; certains cas de reconnexion peuvent ne plus fonctionner, mais ils ne fonctionnaient déjà pas auparavant

3.c) Vulnérabilité des permissions par défaut des PTY (CVE-2025-46803)

  • Dans la version 5.0.0, les permissions par défaut des PTY sont passées de 0620 à 0622 (écriture pour tous)
  • Cela augmente le risque potentiel en matière de sécurité, en particulier parce que tous les utilisateurs peuvent écrire sur les PTY d’autres utilisateurs
  • Ce changement semble avoir été introduit par erreur, et le correctif rétablit la valeur sûre par défaut (0620) à la compilation
  • Arch Linux et NetBSD sont les principaux systèmes affectés

3.d) Divulgation d’informations sur l’existence de fichiers via les messages d’erreur de socket (CVE-2025-46804)

  • En utilisant la variable d’environnement SCREENDIR et les messages d’erreur, il est possible de vérifier avec les privilèges root l’existence réelle de fichiers ou répertoires
  • Il s’agit d’une fuite d’informations mineure, mais le risque existe dans tous les environnements installés en setuid-root

3.e) Condition de concurrence TOCTOU dans l’envoi de signaux (CVE-2025-46805)

  • En raison du décalage temporel entre les fonctions CheckPid() et Kill(), un signal pourrait être envoyé avec les privilèges root à un PID autre que celui visé
  • Comme seuls SIGCONT, SIGHUP et quelques autres signaux sont principalement autorisés, l’impact reste limité, mais peut entraîner un déni de service (DoS) ou une légère atteinte à l’intégrité

3.f) Débordement lors de l’envoi de commandes dû à une mauvaise utilisation de strncpy()

  • Dans la version 5.0.0, une mauvaise utilisation de strncpy() provoque un débordement de tampon et un plantage du programme
  • Si le correctif n’est pas appliqué correctement, l’envoi de commandes peut écraser la mémoire au-delà de MAXPATHLEN et conduire à une indisponibilité du service
  • Ce n’est pas un problème de sécurité, mais une correction rapide est nécessaire pour la stabilité

4. Risques supplémentaires liés à l’implémentation setuid-root

  • Une logique insuffisante dans la gestion des UID de plusieurs utilisateurs a été constatée en mode multi-utilisateur
  • En mode setuid-root, la logique d’abandon des privilèges n’est pas complète
  • Dans les sessions créées par root, la baisse effective des privilèges ne s’effectue pas correctement, ce qui augmente le niveau de risque global

5. Recommandations générales de durcissement

  • Le vaste travail de refactoring a montré un affaiblissement de la logique de sécurité existante
  • Étant donné la nature d’un binaire setuid-root, il est nécessaire d’introduire une suite de tests de sécurité et de concevoir de manière conservatrice tout traitement lié au système de fichiers et aux variables d’environnement
  • L’exécution complète en setuid-root n’est particulièrement pas recommandée ; la fonctionnalité multi-utilisateur devrait être limitée à un mécanisme d’adhésion explicite pour un groupe de confiance
  • Les variables d’environnement (PAH, etc.) doivent impérativement être limitées à des chemins de confiance

6. Problèmes dans la coordination de la divulgation des vulnérabilités

  • Le processus de coordination avec l’upstream a été inefficace, entraînant des retards dans le développement des correctifs et dans la publication
  • La compréhension du code et les capacités de l’upstream étaient insuffisantes, rendant une réponse étroite difficile
  • Les distributions ont finalement pris l’initiative du développement des correctifs, et le rapport a été publié selon un calendrier coordonné
  • Le manque de capacités de maintenance et de gestion du projet Screen lui-même a également été mis en évidence

7. Matrice d’impact

  • Arch Linux (5.0.0, setuid-root) : toutes les vulnérabilités 3.a, 3.b, 3.c, 3.d, 3.e, 3.f s’appliquent
  • Debian/Ubuntu et de nombreuses autres distributions : 3.b (impact partiel)
  • Fedora 42 (5.0.0, setgid-screen) : 3.b (impact partiel), 3.f affecte
  • Gentoo (4.9.1, setgid-utmp) : 3.b (impact partiel), et même impact que 5.0.0 avec un ebuild unstable + drapeau USE multiuser
  • FreeBSD 14.2 (4.9.1, setuid-root) : 3.b, 3.d, 3.e affectent
  • NetBSD 10.1 (5.0.0, setuid-root) : 3.a, 3.b, 3.c, 3.d, 3.e, 3.f affectent
  • OpenBSD 7.7 (4.9.1) : 3.b (impact partiel)
  • openSUSE TW : 3.b (impact partiel)

8. Calendrier

  • 2024-07-01 : réception d’une demande de revue de code de l’upstream
  • 2025-01-08 : début de la revue
  • 2025-02-07 : signalement privé des vulnérabilités à l’upstream, avec demande de divulgation coordonnée
  • 2025-02~04 : discussion autour des correctifs, puis réajustement du calendrier en raison de problèmes liés à la période d’embargo
  • 2025-05-12 : publication du présent rapport et annonce officielle

9. Liens de référence

  • GNU Savannah [page du projet Screen]
  • openSUSE Bugzilla, avec les correctifs associés, les CVE de référence, les rapports de bug et les liens de documentation

À lire aussi

1 commentaires

 
GN⁺ 2025-05-14
Avis Hacker News
  • Screen dispose d’un mode multi-utilisateur qui permet à plusieurs personnes d’accéder à la même session en même temps ; je pense que c’est cette fonctionnalité qui rend possibles des outils comme tmate, et je me demande si tmux a la même vulnérabilité
    • tmux utilise des sockets de domaine Unix ; je ne comprends pas pourquoi screen a choisi une approche setuid, cela ne semble pas nécessiter les privilèges root ; d’après l’explication dans le TFA, les développeurs actuels de screen ne semblent pas maîtriser entièrement la base de code, et auraient donc choisi le mode setuid-root parce qu’il facilitait l’implémentation de la fonctionnalité
    • Cette fonctionnalité est vraiment excellente ; lors de sessions de formation, je donne à chaque étudiant son propre compte de connexion sur mon portable et je limite leur shell ssh à screen -x <fenêtre d’un utilisateur donné>, afin qu’ils ne puissent utiliser que les fenêtres autorisées par cette ACL screen ; j’affiche ensuite l’écran de chaque étudiant un par un via le projecteur ; du coup, le fait que ce soit truffé de failles de sécurité ne me surprend pas
    • J’ai déjà utilisé la commande screen -x
  • Sous Debian, GNU screen n’est pas installé avec les privilèges setuid root
    • Le paquet Debian Stable (bookworm) est trop ancien pour être affecté par la vulnérabilité 5.0.0 ; avant, je n’aimais pas que Debian soit si lent sur les versions logicielles, mais aujourd’hui j’utilise simplement des sources de paquets séparées pour quelques applications dont j’ai besoin en version récente, et j’utilise encore très bien des versions anciennes pour le reste
    • Gentoo, c’est pareil ; en revanche, sous Gentoo, SETGID est défini sur le groupe utmp, sans que je sache vraiment ce que cela implique
    • Sous Slackware 15, screen n’a pas le bit suid
    • Sous Fedora, il semble être installé en setuid
  • Présentation de la version rendue de l’article de blog : https://security.opensuse.org/2025/05/12/screen-security-issues.html
  • J’ai envoyé un e-mail à l’auteur de l’article à propos du manque de documentation sur la fonctionnalité de journalisation de GNU Screen ; je pense que GNU a besoin d’un meilleur système de suivi des issues ; ressource liée : http://www.zoobab.com/screenrc
  • Le comportement observé existe dans Screen depuis 2005 ; cet anti-pattern a longtemps été couvert par des outils comme rkhunter ; je suis presque certain que screen était déjà setuid root dans les années 90
  • Je suis surpris que l’upstream (l’équipe de développement officielle) se soit impliqué cette fois-ci ; il y a environ 5 ans, j’étais attristé par l’impression que le développement de GNU screen s’était complètement arrêté ; je me demande si c’est toujours le cas, et aussi s’il existe une fonctionnalité permettant d’ajouter une nouvelle fenêtre à screen sans s’y attacher à l’écran
    • C’est l’upstream qui a demandé à l’équipe SUSE de faire une revue ; il y a peu de développeurs et la maintenance actuelle semble insuffisante ; si c’est bien le cas, c’est regrettable ; même s’il existe des alternatives comme tmux, beaucoup de gens utilisent Screen depuis longtemps, et c’est dommage de voir cet outil vieillir ainsi
    • Leur seule implication a été de le distribuer en setuid-root ; seules les distributions configurées de cette façon sont vulnérables, les autres ne sont pas concernées ; quand les correctifs officiels tardent, les distributions appliquent directement leurs propres patchs
    • Je ne pense pas qu’il soit forcément mauvais que le développement des outils GNU s’arrête (hors correctifs de bugs) ; cela peut être le signe que les fonctionnalités sont suffisamment abouties
    • La communication avec l’upstream est difficile, donc nous n’avons pas beaucoup de détails sur les correctifs de bugs ou les releases ; une demande de revue de sécurité a été faite, mais ils semblent difficiles à joindre
    • Dans l’open source, même quand un logiciel arrive au bout de son cycle et qu’un remplaçant existe, il y a peu d’incitation à migrer immédiatement, ce qui crée de l’inertie ; à l’inverse, on voit aussi des cas où seul le nom est racheté pour être remplacé par quelque chose de complètement différent, comme Audacity ; il n’y a pas de bonne solution
  • Lien vers la version rendue : https://security.opensuse.org/2025/05/12/screen-security-issues.html
  • Je me demande combien de développeurs utilisent réellement eux-mêmes tous les outils open source populaires, et quelle quantité d’argent circule dans les secteurs qui les utilisent
  • Il me semble que tmux est inclus par défaut dans OpenBSD depuis la version 4.6, et qu’il a été audité ; c’est une bonne alternative pour les personnes plus attentives à la sécurité
    • Le fait de voir screen mentionné m’a rappelé qu’autrefois j’étais passé à tmux, puis je me suis embrouillé en n’utilisant plus screen par habitude
  • C’est amusant de voir screen et setuid mentionnés ensemble ; une fois, pour résoudre un problème étrange, j’avais fait un chmod u+s sur screen ; le simple fait d’avoir à faire ça me paraissait bizarre ; mais j’ai fini par découvrir que screen avait des fonctionnalités qui dépendent de setuid, et que certains systèmes le distribuaient ainsi par défaut ; et après avoir activé u+s, screen lisait le ~/.screenrc de root au lieu de mon ~/.screenrc (je l’ai pris comme une rustine temporaire) ; j’imagine que la prise en charge de setuid peut varier selon les builds de screen
    • C’est ainsi que setuid est censé fonctionner à l’origine ; si on positionne ce bit spécial sur le binaire, cela signifie qu’il doit toujours s’exécuter sous l’utilisateur fourni