Plusieurs failles de sécurité découvertes dans GNU Screen

 (openwall.com)
2 points par GN⁺ 2025-05-14 | 1 commentaires | Partager sur WhatsApp
  • Un audit de sécurité de GNU Screen, centré sur Screen 5.0.0 et les installations setuid-root, a mis au jour une élévation de privilèges locale, un détournement de TTY, des fuites d’informations, une condition de concurrence lors de l’envoi de signaux et un crash lors de l’envoi de commandes
  • La plus grave, CVE-2025-23395, permet à logfile_reopen() de traiter un chemin fourni par l’utilisateur avec les privilèges root, ce qui autorise la création de fichiers possédés par root à des emplacements arbitraires ou l’ajout de logs à des fichiers existants
  • L’ancien fonctionnement du mode multi-utilisateur s’est également révélé problématique : Attach() bascule temporairement le TTY en 0666, ce qui permet à d’autres utilisateurs de le lire, d’y écrire et d’y injecter des entrées
  • Le niveau de risque varie selon les distributions et leur mode d’installation : Arch Linux et NetBSD 10.1 fournissent Screen 5.0.0 en setuid-root et sont fortement touchés par les principales vulnérabilités
  • La recommandation actuelle est de ne pas installer Screen en setuid-root ; la fonction multi-utilisateur devrait reposer sur un opt-in par groupe de confiance, avec baisse des privilèges par défaut, élévation limitée et nettoyage des variables d’environnement

Contexte de publication et correctifs

  • En juillet 2024, le mainteneur upstream de Screen a demandé une revue de la base de code actuelle, et l’audit de sécurité effectif a commencé en janvier 2025
  • L’audit a révélé, dans la mise à jour majeure Screen 5.0.0, un exploit local root affectant les distributions qui le livrent en setuid-root
  • D’autres problèmes de gravité plus faible ont aussi été identifiés, dont certains affectent encore Screen 4.9.1 et les versions antérieures, présentes dans de nombreuses distributions
  • Les problèmes ont été partagés sur la liste de diffusion distros le 30 avril 2025, puis rendus publics le 12 mai 2025
  • Le signalement inclut des lots de correctifs par version

Configuration de Screen et mode multi-utilisateur

  • Screen 5.0.0 a été publié upstream en août 2024 comme version majeure, et Arch Linux, Fedora 42 et NetBSD 10.1 la proposent
  • De nombreuses distributions Linux et UNIX utilisent encore Screen 4.9.1 au moment de la rédaction
  • Le mode multi-utilisateur de Screen permet d’attacher une session Screen appartenant à un autre utilisateur si les identifiants adéquats sont disponibles
    • Cette fonctionnalité n’est utilisable que si Screen est installé avec le bit setuid-root
    • Comme du code Screen complexe s’exécute alors avec les privilèges root, la surface d’attaque s’élargit
  • Parmi les systèmes examinés, Arch Linux, FreeBSD et NetBSD installent Screen en setuid-root
  • Gentoo Linux applique le bit setuid-root lorsque l’option USE "multiuser" est activée
  • Certaines distributions utilisent setgid au lieu de setuid
    • La valeur par défaut de Gentoo Linux est setgid-utmp, ce qui permet à Screen d’écrire des enregistrements de connexion dans la base système utmp
    • Fedora Linux utilise setgid-screen, ce qui permet à Screen de placer des sockets dans le répertoire système /run/screen

CVE-2025-23395 : exploit local root via logfile_reopen()

  • CVE-2025-23395 affecte Screen 5.0.0 lorsqu’il s’exécute avec les privilèges setuid-root
  • La fonction logfile_reopen() traite un chemin fourni par l’utilisateur sans abaisser les privilèges
  • Un utilisateur non privilégié peut créer des fichiers arbitraires avec les propriétés suivantes
    • propriétaire : root
    • groupe : groupe réel de l’utilisateur appelant
    • mode de fichier : 0644
  • Les fichiers déjà existants peuvent aussi être exploités
    • Les données écrites sur le PTY Screen sont ajoutées à ce fichier
    • Le mode et le propriétaire du fichier existant ne sont pas modifiés
  • Screen abaisse correctement les privilèges lors de l’ouverture initiale du fichier de log, mais une élévation de privilèges devient possible lorsqu’il décide qu’il faut rouvrir ce fichier
  • Dans le contrôle stolen_logfile(), logfile_reopen() est appelé si le nombre de liens du fichier de log d’origine devient 0 ou si sa taille change de manière inattendue
  • Un utilisateur non privilégié peut provoquer intentionnellement cette condition
  • Le patch 0001 pour Screen 5.0.0 réintroduit une gestion sûre des fichiers lors de la réouverture du fichier de log
  • Le problème provient d’un ancien commit 441bca708bd qui a supprimé lf_secreopen(), changement inclus dans la version 5.0.0

CVE-2025-46802 : détournement de TTY lors de l’attachement à une session multi-utilisateur

  • CVE-2025-46802 se produit dans la fonction Attach() lorsque l’indicateur multiattach est défini
  • Lors de l’attachement à une session multi-utilisateur, Screen modifie via chmod() le mode du TTY courant en 0666
  • Le chemin du TTY est vérifié, notamment pour s’assurer qu’il se trouve sous /dev et que isatty() est vrai ; ce comportement seul ne constitue donc pas un exploit root local distinct
  • Le problème est qu’une condition de concurrence apparaît pendant l’assouplissement temporaire des permissions du TTY, permettant à d’autres utilisateurs de lire et d’écrire sur ce TTY
  • Lors d’un test simple basé sur l’API Linux inotify, un script Python parvenait à ouvrir le TTY affecté toutes les deux ou trois tentatives
  • Un attaquant peut alors
    • intercepter les données saisies sur le TTY
    • injecter des données dans le TTY
    • tromper l’utilisateur pour lui faire saisir un mot de passe
    • injecter des séquences de contrôle afin de perturber la victime ou de viser des problèmes propres à l’émulateur de terminal utilisé
  • Dans certains chemins de retour de Attach(), le mode initial du TTY n’est pas restauré
    • Exemple : si la session cible est introuvable et que l’argument "quiet" est défini
  • Le correctif supprime le chmod() temporaire
    • patch 0001 pour Screen 4.9.1
    • patch 0004 pour Screen 5.0.0
  • Peu avant la publication, il a été constaté que ce correctif pouvait casser certains cas de reattach, mais il s’est avéré que ces cas étaient déjà cassés dans Screen 4.9.1
  • Le problème existe au moins depuis les versions de Screen publiées après 2005 et affecte les distributions Linux et les BSD qui proposent le support multi-utilisateur en setuid-root
  • Même sans setuid-root, le problème peut théoriquement exister puisqu’un utilisateur peut modifier le mode de son propre TTY, mais Screen ne peut pas poursuivre vers la session d’un autre utilisateur sans privilèges root

CVE-2025-46803 : valeur par défaut world-writable pour les PTY dans Screen 5.0.0

  • CVE-2025-46803 correspond au changement, dans Screen 5.0.0, du mode par défaut des PTY alloués par Screen, passé de 0620 à 0622
  • Avec cette valeur par défaut, n’importe quel utilisateur du système peut écrire sur un PTY Screen
  • Cela entraîne des problèmes de sécurité similaires à CVE-2025-46802, mais sans l’aspect fuite d’informations
  • Dans Screen 4.9.1, la valeur par défaut au niveau du code était 0622, mais la valeur par défaut 0620 fournie par la configuration autotools prévalait, ce qui donnait un réglage sûr par défaut
  • Dans Screen 5.0.0, configure.ac a été réécrit, la valeur par défaut 0620 au niveau autoconf a disparu, puis l’option de configuration pty-mode a été réintroduite avec 0622 comme valeur par défaut
  • Les notes de version de 5.0.0 n’ont pas été retrouvées, seuls quelques éléments du ChangeLog étaient disponibles, et ce changement de mode PTY par défaut ne semble pas avoir été intentionnel
  • Le patch 0002 pour Screen 5.0.0 rétablit un mode PTY sûr par défaut dans configure.ac
    • L’application de ce changement nécessite d’exécuter autoreconf
  • Il est recommandé aux packageurs de passer explicitement l’option de configuration --with-pty-mode=0620
  • Gentoo Linux et Fedora Linux passent explicitement une valeur sûre pour --with-pty-mode
  • Arch Linux et NetBSD ne passent pas cette option, héritent donc de la nouvelle valeur par défaut et sont vulnérables

CVE-2025-46804 : divulgation de l’existence de fichiers via les messages d’erreur sur le chemin du socket

  • CVE-2025-46804 est une fuite d’informations mineure lorsque Screen s’exécute avec les privilèges setuid-root
  • Le problème est présent à la fois dans les anciennes versions de Screen et dans la 5.0.0
  • Screen vérifie SocketPath avec les privilèges root et divulgue dans ses messages d’erreur des informations de chemin qu’un utilisateur non privilégié ne devrait normalement pas connaître
  • En utilisant la variable d’environnement SCREENDIR, on peut inférer par exemple
    • si /root/.lesshst est un fichier ordinaire
    • si le répertoire /root/.cache existe
    • si le chemin /root/test n’existe pas
  • Le correctif modifie le comportement sur les installations setuid-root pour n’afficher qu’un message d’erreur générique lorsque le chemin cible n’est pas contrôlé par l’UID réel du processus
    • patch 0002 pour Screen 4.9.1
    • patch 0005 pour Screen 5.0.0
  • Toutes les distributions examinées sont affectées

CVE-2025-46805 : condition de concurrence TOCTOU lors de l’envoi de signaux

  • CVE-2025-46805 est une condition de concurrence TOCTOU lors de l’envoi d’un signal à un PID fourni par l’utilisateur dans un contexte setuid-root
  • CheckPid() abaisse les privilèges vers l’UID réel afin de vérifier si le noyau autorise l’envoi d’un signal au PID visé
  • Le signal effectif est envoyé plus tard via Kill(), et peut alors utiliser les privilèges root
  • Entre la vérification et l’envoi réel, le PID contrôlé peut être remplacé par un autre processus privilégié
  • Il pourrait aussi être possible de tromper un processus démon Screen privilégié pour qu’il s’envoie un signal à lui-même
  • Actuellement, seuls SIGCONT et SIGHUP peuvent être envoyés, ce qui limite vraisemblablement l’impact à un déni de service local ou à une atteinte mineure à l’intégrité
  • Le problème résulte d’une correction incomplète de CVE-2023-24626
    • Avant cette correction, ces signaux pouvaient être envoyés à des processus arbitraires même sans condition de concurrence
  • Le correctif fait en sorte que l’envoi réel du signal s’effectue lui aussi avec les privilèges de l’UID réel, comme dans CheckPid()
    • patch 0003 pour Screen 4.9.1
    • patch 0006 pour Screen 5.0.0
  • Toutes les distributions examinées sont affectées

Crash lors de l’envoi de commandes à cause de l’usage de strncpy() dans Screen 5.0.0

  • Screen 5.0.0 contient aussi un problème lié à strncpy() qui n’est pas considéré comme une faille de sécurité, mais qui doit être corrigé en priorité
  • Dans le commit 0dc67256, plusieurs appels à strcpy() ont été remplacés par strncpy()
  • strncpy() n’est pas une fonction de manipulation sûre des chaînes, mais une fonction qui remplit de 0 un tampon de taille fixe ; elle écrit donc des 0 jusqu’à la fin du tampon cible même après le premier octet \0
  • Dans la boucle de traitement des arguments de ligne de commande de attacher.c, MAXPATHLEN est encore passé comme taille de destination après la première itération
  • Comme le pointeur p a déjà été incrémenté, transmettre toujours la même taille fait que les appels suivants à strncpy() écrivent des octets \0 au-delà de la fin du tampon
  • Sur Arch Linux, l’envoi de plus d’un argument de commande à une session Screen en cours a produit, sur des builds avec _FORTIFY_SOURCE, les erreurs suivantes
    • *** buffer overflow detected***: terminated
    • Aborted (core dumped)
  • Sans _FORTIFY_SOURCE, il peut ne pas y avoir d’erreur visible, et même avec -fsanitize=address, aucune erreur peut ne se manifester
  • L’appelant peut écraser de 0 les MAXPATHLEN octets situés après le tampon cmd, mais comme il existe juste après un tampon writeback[MAXPATHLEN] de même taille, il est jugé peu probable qu’un attaquant puisse en tirer un avantage exploitable
  • Le patch 0003 pour Screen 5.0.0 remplace strncpy() par snprintf() et transmet correctement la taille restante du tampon de destination
  • Toutes les distributions qui fournissent Screen 5.0.0 sont affectées

Impact selon les distributions

Système Version de Screen Privilège spécial Impact
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 aucun 3.b partiel
Ubuntu 24.04.2 4.9.1 aucun 3.b partiel
Fedora 42 5.0.0 setgid-screen 3.b partiel, 3.f
Gentoo 4.9.1 setgid-utmp, setuid-root si l’option USE multiuser est activée 3.b partiel
openSUSE TW 4.9.1 aucun 3.b partiel
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 aucun 3.b partiel

Inquiétudes sur la conception setuid-root et recommandations

  • Le mode multi-utilisateur de Screen implique trois UID distincts
    • l’effective UID 0 pour les opérations privilégiées
    • l’UID réel de l’utilisateur qui a créé la session
    • l’UID réel de l’utilisateur qui s’attache à la session
  • Le code actuel de Screen semble difficile à structurer de façon à refléter correctement cette distinction
  • Une session Screen multi-utilisateur créée par root “abaisse ses privilèges” vers l’UID réel du créateur de session, c’est-à-dire 0, ce qui revient en pratique à ne pas abaisser les privilèges du tout
  • Lors du refactoring de Screen 5.0.0, une logique de sécurité présente depuis longtemps a été cassée, entraînant CVE-2025-23395 et CVE-2025-46803
  • Avant d’autres refactorings, une suite de tests capable de valider les propriétés de sécurité de l’implémentation est nécessaire
  • Les développeurs qui manipulent des binaires setuid-root doivent comprendre les risques propres à ce domaine
  • Screen continue à s’exécuter avec des privilèges élevés, puis n’abaisse ses privilèges que de façon sélective pour certaines opérations jugées dangereuses
  • Un programme setuid-root robuste devrait au contraire abaisser ses privilèges par défaut, puis ne les réélever que pour les opérations qui en ont réellement besoin
  • En contexte setuid-root, il faut une logique qui supprime toutes les variables d’environnement sauf celles explicitement autorisées
  • Des variables comme PATH devraient être nettoyées pour ne pointer que vers des répertoires système de confiance
  • Pour l’instant, il est recommandé de ne pas installer Screen en setuid-root, non seulement en 5.0.0 mais aussi dans les versions précédentes de la série 4.9
  • Une alternative consiste à proposer la fonctionnalité multi-utilisateur en mode opt-in et à réserver l’exécution d’une version multi-utilisateur de Screen aux membres d’un groupe de confiance

Coordination de la divulgation et état de l’upstream

  • En février 2025, les problèmes ont été signalés en privé à l’upstream de Screen, avec une proposition de divulgation coordonnée
  • L’upstream s’est montré favorable au maintien de la confidentialité avant publication afin de corriger les bugs, et a indiqué avoir besoin d’un à deux mois
  • Environ un mois plus tard, des échanges sur les correctifs et une certaine activité côté upstream ont commencé, mais les discussions n’ont pas été assez productives
  • À l’approche de la limite d’embargo de 90 jours, il n’y avait toujours pas eu de communication supplémentaire ; entre-temps, des distributions comme NetBSD avaient migré vers Screen 5.0.0 et se retrouvaient alors pleinement affectées par CVE-2025-23395
  • Il a été estimé que l’upstream n’était pas suffisamment familier avec la base de code Screen et ne comprenait pas totalement les problèmes de sécurité signalés
  • L’upstream souhaitait une publication plus rapide alors que certains problèmes restaient non résolus, ce qui a conduit à l’envoi rapide d’un brouillon sur la liste de diffusion distros
  • SUSE a ensuite développé directement les correctifs manquants, puis ajusté et documenté des patchs qui n’avaient été discutés qu’à l’état de brouillon côté upstream
  • Il est estimé qu’avec une capacité upstream dédiée, la procédure de divulgation coordonnée aurait pu être bouclée en environ deux semaines
  • L’upstream de Screen semble souffrir d’un manque de ressources et d’expertise, ce qui est préoccupant pour un utilitaire open source largement utilisé

Principales dates

  • 2024-07-01 : transmission de la demande de revue par l’upstream
  • 2025-01-08 : début de l’audit de sécurité
  • 2025-02-07 : signalement privé à l’upstream de Screen et proposition de divulgation coordonnée
  • 2025-02-11 : création d’un bug privé dans le bug tracker GNU Savannah
  • 2025-04-30 : décision d’attribution des CVE et partage d’un brouillon sur la liste de diffusion distros
  • 2025-05-07 : partage, avec la liste distros et l’upstream, des versions finales des correctifs pour Screen 4.9.1 et 5.0.0
  • 2025-05-12 : publication du rapport sur le blog et la liste de diffusion oss-security

À lire aussi

1 commentaires

 
GN⁺ 2025-05-14
Commentaires sur Hacker News

  • Je ne savais pas que Screen avait ce mode multi-utilisateur, mais c’est probablement ce qui rend possibles des outils comme tmate
    Avec les identifiants appropriés, on peut s’attacher à une session Screen appartenant à un autre utilisateur, et cette fonctionnalité ne serait possible que si Screen est installé en setuid-root
    Du coup, je me demande si tmux est concerné par le même type de vulnérabilité

    • tmux n’est pas concerné, car il utilise des sockets de domaine Unix
      Je ne sais pas pourquoi screen a choisi ici l’approche setuid, et les droits root ne semblent pas du tout nécessaires
      Plus bas dans l’article, il y a une explication plausible selon laquelle les développeurs actuels de screen ne connaissent pas parfaitement la base de code ; si c’est le cas, il est possible que setuid-root ait été la façon la plus simple de faire fonctionner la fonctionnalité
    • C’est une fonctionnalité plutôt excellente
      Lors de sessions de formation, j’ai déjà donné à chaque étudiant un compte de connexion sur mon ordinateur portable, limité leur shell SSH à screen -x, puis utilisé les listes de contrôle d’accès de screen pour que chaque étudiant ne puisse utiliser que sa propre fenêtre
      Pendant les travaux pratiques, en tant que propriétaire de screen, je pouvais afficher l’écran de chaque étudiant au projecteur pour que toute la classe voie le résultat
      Ça ne m’étonnerait pas qu’il y ait beaucoup de failles de sécurité
    • Exact, screen -x

  • Sur Debian, GNU screen n’est pas installé avec les droits setuid-root

    • Le paquet de Debian Stable, c’est-à-dire bookworm, est trop ancien pour être affecté par la vulnérabilité 5.0.0
      Avant, je n’aimais pas que Debian soit toujours en retard sur les versions des logiciels, mais maintenant j’utilise d’autres sources de paquets seulement pour quelques applis pour lesquelles je ne veux vraiment pas dépendre de logiciels très anciens, comme les navigateurs, et je vis très bien avec les vieux paquets pour le reste
    • Sur Slackware 15, /usr/bin/screen pointe vers screen-4.9.0, et l’exécutable n’est pas suid non plus
    • Même chose sur Gentoo
      En revanche, sur Gentoo, SETGID est activé pour le groupe utmp, mais je ne sais pas vraiment quelles en sont les conséquences
    • Sur Fedora, il semble être setuid-root

  • L’article de blog rendu est ici : https://security.opensuse.org/2025/05/12/screen-security-iss...

  • J’avais déjà envoyé un e-mail à l’auteur de GNU Screen pour lui signaler que la fonctionnalité de journalisation dans un fichier n’était pas correctement documentée : http://www.zoobab.com/screenrc
    GNU a besoin d’un meilleur système de suivi des tickets

    • Il y avait eu une session de questions-réponses avec l’auteur de Tmux, et il se plaignait déjà du manque de documentation il y a environ 16 ans
      https://undeadly.org/cgi?action=article&sid=20090712190402
    • C’est documenté en détail dans le manuel de GNU screen : https://www.gnu.org/software/screen/manual/screen.html#Log
    • Beaucoup de vieux projets ont le problème que les tickets finissent enterrés dans les profondeurs infinies de listes de diffusion non indexées
      Les critiques contre Discord, accusé de rendre ce genre d’informations inaccessible, sont justifiées, mais l’IRC que certains projets utilisent encore est en pratique deux fois pire
      J’aimerais que ces projets migrent vers des plateformes comme Gitea, Forgejo, Codeberg, GitLab ou GitHub, afin de regrouper les informations pertinentes et de garantir leur découvrabilité

  • Zellij est une très bonne alternative moderne à screen et tmux ; ses valeurs par défaut sont excellentes et son UI est bien conçue pour être facile à découvrir
    Je le recommande à ceux qui trouvaient que le rapport effort/bénéfice des multiplexeurs de terminaux était ambigu
    https://zellij.dev
    https://github.com/zellij-org/zellij

    • Je l’ai essayé il y a quelques années et il était assez soigné
      Mais par rapport à tmux, la latence était perceptible, et j’utilise toujours tmux
      J’étais déjà sur une connexion avec de la latence à l’époque, donc j’étais peut-être un peu sensible à ce point
    • La dernière fois que j’ai regardé Zellij, il semblait être un excellent nouveau projet dans l’écosystème des multiplexeurs, mais il ne prenait pas en charge de mécanisme de copier-coller entièrement au clavier
      J’utilise énormément cette fonctionnalité, donc je ne peux pas m’en passer, et tant qu’elle ne sera pas ajoutée, je suis obligé d’utiliser tmux
    • C’est bien, mais j’aime vraiment screen et les commandes sont déjà ancrées dans ma mémoire musculaire
      Je l’utilise depuis plus de 20 ans

  • Je suis surpris que l’amont ait été impliqué là-dedans
    Il y a environ cinq ans, j’avais tristement conclu que le développement de GNU screen s’était complètement arrêté ; je me demande donc si ce n’est finalement pas le cas
    Je ne sais pas si screen a encore une fonctionnalité permettant d’ajouter une nouvelle fenêtre sans s’attacher à un screen existant

    • L’amont a demandé à l’équipe SUSE d’y jeter un œil
      Ils manquent de développeurs, et il se pourrait que l’amont n’ait pas l’expertise nécessaire pour assurer correctement la maintenance
      Si c’est vrai, c’est triste. Je sais qu’il existe tmux et d’autres alternatives, mais beaucoup de gens utilisent Screen depuis très longtemps, et c’est dommage de voir un outil se dégrader lentement
    • Il est indiqué qu’en raison de difficultés de communication avec l’amont, ils ne disposent actuellement pas d’informations détaillées sur les corrections de bugs et les versions publiées de ce côté-là
      Ils ont bien demandé un audit de sécurité, mais il semble qu’il ait été difficile de garder le contact, et je ne connais pas toute l’histoire
    • L’implication, c’est surtout de l’avoir distribué en setuid-root
      Les distributions configurées ainsi sont vulnérables, celles qui ne le sont pas ne le sont pas
      Je vois ça comme une implication très superficielle. Si l’amont est trop lent, les distributions patchent
    • Le fait que le développement d’outils GNU s’arrête n’est pas forcément triste. En dehors des corrections de bugs, bien sûr
      On peut surtout y voir le signe d’un outil achevé
    • Dans l’open source, il y a un problème d’inertie lorsqu’un logiciel arrive en fin de vie et qu’un autre logiciel est créé pour le remplacer
      Il n’y a pas d’incitation à basculer immédiatement, car ce n’est pas une mise à jour mais une migration
      À l’inverse, il est aussi mauvais que quelqu’un rachète la marque d’un logiciel existant et le transforme en quelque chose de complètement différent, comme avec Audacity
      Je ne vois donc pas de bonne solution

  • Version rendue : https://security.opensuse.org/2025/05/12/screen-security-iss...

  • Si ma mémoire est bonne, tmux est entré dans le système de base à partir d’OpenBSD 4.6, et c’est un outil qui a été audité, ou qui l’est régulièrement
    C’est une bonne option pour ceux qui veulent une alternative un peu plus sûre

    • Revoir screen me rappelle l’époque où j’étais passé à tmux et où j’avais fini par oublier screen

  • Le comportement observé existait dans les versions de Screen au moins depuis 2005 ; c’était déjà un anti-pattern depuis aussi longtemps, et des outils comme rkhunter le prenaient aussi en compte
    Cela dit, il me semble que screen était déjà setuid root dans les années 90

  • Combien de développeurs font réellement tourner les outils open source les plus populaires ?
    Et combien d’argent y a-t-il dans les industries qui les utilisent ?