Livre I — Le sol des sujets

Chapitre 4 — Le mainteneur de log4j

Le 9 décembre 2021, à 14h51 GMT, un message paraît sur la liste de diffusion oss-security[1]. Sujet, Log4j 0day RCE. Le fichier en cause est log4j-core-2.14.0.jar. Quelques centaines de kilo-octets d'archive Java, compressés selon le standard ZIP. À l'intérieur, des classes compilées. Une bibliothèque. Quelque chose qu'on appelle un jar, Java archive, et qui dort dans des dépôts privés ou publics jusqu'à ce qu'un programme l'invoque.

Le jar ne fait rien tout seul. Il attend qu'un autre code l'appelle pour écrire des journaux d'événements. Logger un login, logger une erreur, logger une requête. C'est sa fonction. Discrète. Indispensable. Présente partout.

À 14h51 GMT, ce qui devient public, c'est qu'une chaîne de caractères passée dans n'importe quel champ qu'un serveur loggerait permet de lui faire exécuter du code arbitraire à distance. La vulnérabilité reçoit le numéro CVE-2021-44228[2]. Le score CVSS est 10 sur 10. Le maximum. La classification du NIST parle de critical. La presse spécialisée parlera de log4shell.

Le jar ne change pas. Il n'a pas changé. C'est sa fonction qui se révèle, telle qu'elle a toujours été, dans une lumière qu'elle n'avait pas demandée.

Le fichier log4j-core-2.14.0.jar est maintenu, à la date du 9 décembre 2021, par une poignée de bénévoles regroupés dans le Project Management Committee du projet Apache Logging Services. Deux noms reviennent dans les heures qui suivent la publication, parce que ce sont eux qui doivent corriger. Volkan Yazıcı, ingénieur basé en Allemagne, employé par une autre entreprise, contributeur log4j sur son temps libre. Ralph Goers, basé aux États-Unis, mainteneur historique du projet[3]. Aucun des deux n'est rémunéré par la Fondation Apache pour le maintien de log4j. Ils corrigent. Ils releasent. Ils répondent aux courriels qui affluent.

La vulnérabilité avait été signalée à Apache le 24 novembre 2021 par Chen Zhaojun, ingénieur sécurité chez Alibaba Cloud[4]. Quinze jours pour corriger une faille présente dans la bibliothèque depuis la version 2.0-beta9, sortie en juillet 2013. Huit ans de présence silencieuse. Le code fautif, une fonctionnalité de lookup qui résolvait dynamiquement des chaînes de format au moment du logging, avait été ajouté pour répondre à des besoins d'intégration JNDI[5]. Personne n'avait audité. Personne n'avait écrit de fuzzer ciblé. Personne n'avait été payé pour le faire.

Eghbal a posé la formule. Open source is an infrastructure problem disguised as a licensing problem[6]. La phrase est sèche. Elle dit ce qu'elle dit. Le débat qui dure depuis Stallman sur la liberté du code, sur le copyleft, sur les quatre libertés, sur la GPL contre les licences permissives, ce débat masque un autre problème. Pas un problème de licence. Un problème d'infrastructure. Qui maintient. Qui répond. Qui patche à 14h51 GMT un jeudi de décembre.

Le jar log4j-core-2.14.0.jar est utilisé. Le verbe est faible. Le rapport de la CISA publié en juillet 2022 documente 7 400 produits commerciaux distincts contenant la bibliothèque vulnérable[7]. Les services cloud d'Amazon, d'Apple iCloud, de Microsoft Azure, de Cisco, de VMware, de Tesla, de Steam, de Twitter, de Cloudflare. Les routeurs de bureau. Les caisses enregistreuses. Les voitures connectées. Le code ferroviaire allemand. Des systèmes du Department of Defense américain. Le jar, dans des centaines de millions d'instances, écrivait des lignes de log dans des fichiers que personne ne lisait, jusqu'au moment où quelqu'un a su qu'on pouvait y injecter une chaîne ${jndi:ldap://...} et faire exécuter ce qu'on voulait.

Volkan Yazıcı, dans une interaction GitHub publique du 12 décembre 2021, écrit ceci : Log4j maintainers have been working sleeplessly on mitigation measures; fixes, docs, CVE, replies to inquiries, etc. Yet nothing is stopping people to bash us, for work we aren't paid for, for a feature we all dislike yet needed to keep due to backwards compatibility concerns[8]. La traduction française appauvrit. Travail non rémunéré. Fonctionnalité que nous n'aimions pas. Compatibilité ascendante. Il finit par fermer l'issue. Trop de monde s'agglutine.

C'est ici que la grille C opère. Le sujet de la production immatérielle, celui que Virno appelait general intellect, n'est pas l'image qu'on s'en faisait. Ce n'est pas seulement le travailleur cognitif métropolitain qui code dans un open space de Berlin ou de San Francisco. Ce n'est pas seulement le hacker raymondien de la Cathedral and the Bazaar, méritocratique et reconnu. C'est aussi un homme à Düsseldorf qui répond à des courriels dans la nuit du 9 au 10 décembre 2021, parce que la moitié des serveurs du monde dépendent d'un fichier qu'il maintient sur son temps libre, et parce qu'il n'y a personne d'autre.

La capture est ici, dans l'asymétrie. Amazon Web Services facture, en 2021, 62 milliards de dollars de chiffre d'affaires[9]. Microsoft Azure, 75 milliards. Apple iCloud génère des revenus dont la décomposition n'est pas publiée, mais qui se chiffrent en milliards. Aucun de ces géants n'employait, le 8 décembre 2021, un seul ingénieur dont la fiche de poste contenait la phrase maintenir la bibliothèque log4j-core. La valeur était utilisée. Le coût n'était pas porté.

Stallman avait posé la question politique en 1985. Le code propriétaire est un exercice de pouvoir, le copyleft est un dispositif juridique qui retourne le droit d'auteur contre lui-même[10]. Free software, not free beer. La liberté du code, pas la gratuité. Sergio Amadeu da Silveira, à São Paulo, l'avait traduit dans un autre vocabulaire, celui de la souveraineté numérique des pays du Sud. La licence permissive est un cadeau au Nord. Le copyleft est un contrat entre égaux[11]. Ces formulations restent. Mais elles ne disent rien du préfet du jar. Elles disent ce que le code peut être, juridiquement. Elles ne disent pas qui maintient.

Lessig avait formulé l'autre versant. Code is law[12]. L'architecture technique régule plus efficacement que le droit. Une boucle d'authentification, un protocole, une API, une bibliothèque de log. Régulation invisible. Régulation non débattue. Mais Lessig, en 1999, n'imaginait pas que la régulation par le code reposerait, deux décennies plus tard, sur le travail bénévole de quelques personnes physiques dont la défaillance individuelle pourrait paralyser des chaînes industrielles entières. Le code est la loi, soit. Le mainteneur est qui.

Benkler avait théorisé en 2006 la commons-based peer production[13]. Wikipédia, Linux, l'écosystème libre. Production coopérative, décentralisée, non propriétaire. Le modèle tenait. Il tient encore, partiellement. Mais Benkler ne voyait pas que la coopération distribuée se concentre, en pratique, sur des goulots étroits. Le ratio que Nielsen a documenté empiriquement, 90 / 9 / 1, vaut pour Wikipédia comme pour log4j. Quatre-vingt-dix pour cent de lecteurs passifs. Neuf pour cent de contributeurs occasionnels. Un pour cent qui maintient. Quand le pour cent fatigue, la base de données fait ce qu'elle peut. Quand le pour cent s'épuise sur log4j, la planète informatique tousse.

La gouvernance protocolaire de l'IETF a posé une formule, en 1992, par la voix de David Clark. We reject kings, presidents and voting. We believe in rough consensus and running code[14]. La formule est belle. Elle exclut ce qui ne se code pas. Elle exclut, par construction, la question de qui peut coder, qui peut consacrer du temps à coder sans contrepartie, qui peut s'asseoir à 14h51 un jeudi pour répondre à des courriels accusateurs. Le running code qui tourne suppose un corps qui le fait tourner. Le corps n'apparaît pas dans la formule. Il est invisible parce qu'il est supposé. Il est supposé parce qu'il a toujours été là, gratis et amore. La phrase ne tient plus.

Da Silveira, depuis Brasília, le voyait autrement. La logique permissive, MIT, BSD, Apache, qui domine l'écosystème log4j, externalise le travail vers les communautés qui acceptent de produire sans contrepartie, et internalise la valeur dans les entreprises qui n'ont aucune obligation de réciprocité[15]. La GPL aurait, en théorie, contraint la rétribution. La licence Apache 2.0 sous laquelle log4j est distribué ne contraint rien. Volkan Yazıcı, en décembre 2021, ne peut juridiquement rien réclamer aux multinationales qui dépendent de son code. Il peut se taire ou écrire un message GitHub que les médias relayeront comme une curiosité.

Ce qui rend la situation lisible n'est pas le scandale. Ce n'est pas non plus l'indignation rétrospective, ni les promesses de financement qui ont suivi[16]. C'est ce que la situation rendait visible et qui était déjà là. Le jar, le mainteneur, la chaîne d'extraction de valeur. La structure existait avant log4shell. Log4shell l'a éclairée pendant quelques semaines. Puis l'éclairage est retombé.

Le clou ne demande rien. Il tient. Sa tête ronde dépasse à peine du bois. Il rouillera en place. C'est sa manière à lui de durer. Le jar log4j-core-2.14.0.jar n'est plus la version courante. La version 2.17.1, sortie le 28 décembre 2021, a corrigé la faille, puis deux autres qui ont émergé dans les jours suivants[17]. Mais le jar est encore présent dans des centaines de milliers de systèmes qui n'ont pas été mis à jour. Il continuera de l'être. Il maintient ce qu'il maintient.

Volkan Yazıcı a continué à contribuer après décembre 2021. Ralph Goers aussi. La Fondation Apache n'emploie toujours pas de mainteneur log4j à plein temps. Les promesses de financement ont produit, sur trois ans, quelques bourses ponctuelles et un projet Alpha-Omega de l'Open Source Security Foundation[18]. Le ratio entre la valeur captée par l'écosystème et le coût porté par les mainteneurs n'a pas substantiellement bougé. La structure tient parce que la structure tient. Quelqu'un finit toujours par maintenir, par fatigue, par habitude, par sens du devoir.

Le sujet open-source n'est pas l'utopie californienne du commun horizontal. Ce n'est pas non plus la communauté méritocratique idéalisée par Raymond. C'est une figure précaire dont la précarité est structurelle, pas accidentelle. Elle ne se résout pas par GitHub Sponsors. Elle ne se résout pas par les bourses Alpha-Omega. Elle est ce qu'elle est, et elle est utile à ceux qui en bénéficient précisément parce qu'elle est ce qu'elle est.

À 14h51 GMT, le 9 décembre 2021, un homme à Düsseldorf a vu l'écran s'allumer.

1. La divulgation publique a eu lieu via la liste oss-security du Open Source Security Project, archivée sur seclists.org/oss-sec/2021/q4/146. L'horaire de 14h51 GMT correspond à l'horodatage du premier message public ; les horaires antérieurs renvoient à la chaîne de divulgation responsable initiée par Alibaba Cloud le 24 novembre 2021.

2. CVE-2021-44228, Apache Log4j2 Remote Code Execution Vulnerability, base NIST NVD, score CVSS 3.1 = 10.0, classification Critical. Publié le 10 décembre 2021 dans la base.

3. Composition du Project Management Committee Apache Logging Services, archives publiques de la fondation, logging.apache.org/team-list.html, état au 9 décembre 2021. Volkan Yazıcı, employé par Wisemen, contributeur log4j sur temps libre. Ralph Goers, Chair du PMC en 2021.

4. Chen Zhaojun, Alibaba Cloud Security Team, signalement initial à la fondation Apache le 24 novembre 2021. Documenté par le rapport CSRB, Review of the December 2021 Log4j Event, Cyber Safety Review Board, Department of Homeland Security, juillet 2022, p. 11.

5. La fonctionnalité Lookups a été introduite dans log4j 2.0-beta9 (juillet 2013) avec le support du préfixe jndi. Documentation Apache, Lookups, logging.apache.org/log4j/2.x/manual/lookups.html. JNDI, Java Naming and Directory Interface.

6. Nadia Eghbal, Working in Public: The Making and Maintenance of Open Source Software, Stripe Press, San Francisco, 2020, p. 78. ISBN 978-0-578-67586-2.

7. Cyber Safety Review Board, Review of the December 2021 Log4j Event, U.S. Department of Homeland Security, juillet 2022, p. 17. Recensement de 7 400 produits affectés.

8. Volkan Yazıcı, message public sur GitHub, issue Apache Logging, 12 décembre 2021, archivé. Repris notamment par The Guardian, 13 décembre 2021, et Bloomberg, 14 décembre 2021.

9. Amazon, Annual Report 2021, segment AWS, chiffre d'affaires 2021 de 62,2 milliards de dollars. Microsoft, Annual Report FY2022, segment Intelligent Cloud (incluant Azure), 75,3 milliards de dollars.

10. Richard M. Stallman, Free Software, Free Society, GNU Press, Boston, 2002, p. 31, p. 56, p. 120. Notamment, Proprietary software is an exercise of power.

11. Sergio Amadeu da Silveira, Software Livre: A luta pela liberdade do conhecimento, Editora Fundação Perseu Abramo, São Paulo, 2004, p. 45. Paraphrase documentée par Yuri Takhteyev, Coding Places, MIT Press, 2012, p. 87.

12. Lawrence Lessig, Code and Other Laws of Cyberspace, Basic Books, New York, 1999, chapitre 1. Repris dans Code: Version 2.0, 2006, p. 6.

13. Yochai Benkler, The Wealth of Networks: How Social Production Transforms Markets and Freedom, Yale University Press, 2006, p. 60.

14. David D. Clark, A Cloudy Crystal Ball — Visions of the Future, présentation à l'IETF 24, Cambridge (MA), 13-17 juillet 1992, transcription archivée par l'IETF.

15. Da Silveira, op. cit., p. 45 et suivantes ; voir également Annexe A du présent dossier, fiche da Silveira.

16. White House Open-Source Security Summit, 13 janvier 2022. National Cybersecurity Strategy, U.S. Government, 2 mars 2023, qui reconnaît explicitement la dépendance à des mainteneurs non rémunérés comme risque de sécurité nationale.

17. Apache Logging Services, release notes log4j 2.17.1, 28 décembre 2021. Corrige CVE-2021-44832 après les patchs initiaux 2.15.0 (10 décembre) et 2.16.0 (13 décembre).

18. Open Source Security Foundation, projet Alpha-Omega, lancé en février 2022 avec un financement initial de 5 millions de dollars de Microsoft, Google et Amazon. Bilan triennal publié en 2025, openssf.org/projects/alpha-omega.