La bibliothèque qui fait couler autant d'encre qu'elle ne logue — Vous pensiez qu'on en avait terminé avec LA bibliothèque de journalisation Java, Apache Log4J ?
Et bien non ! Après les péripéties de fin 2021, la cybersécurité américaine y a été de sa petite code review.
Le comité de cybersécurité américain CSRB (Cyber Safety Review Board) a en effet publié un rapport de 52 pages précisant l'historique de la découverte de cette faille, qui date de bientôt un an, ses impacts passés et à venir, mais également ses recommandations pour le futur.
Ce comité, créé le 3 février 2022 (ère Biden) dans le but de mieux contrôler de prévenir tout risque lié au développement de logiciels qui pourrait nuire aux intérêts de différentes organisations, entreprises et/ou individus, dépend directement du département de la Sécurité intérieure des États-Unis (rien que ça !) et est composé d'élus et de grandes entreprises informatiques (guess who? 👀).
Et pour sa première affaire, le CSRB s'est donc penché sur... notre bon vieil utilitaire Log4J !
(Coucou les devs Java)
Le 11 juillet 2022 (et un peu en mode ninja commit), ce beau petit monde a donc publié un rapport au sujet des vulnérabilités découvertes en pagaille 7 mois plus tôt.
Ce document est plutôt bien structuré sans pour autant trop rentrer dans les détails techniques (pour cela, il suffit de se rendre sur le repo Github de Log4j 😉).
Plusieurs informations y sont présentées, comme une timeline des différents événements majeurs depuis la découverte de la vulnérabilité, ainsi que des recommandations, ou encore des arguments montrant la gravité de la situation...
En parlant de situation dangereuse, il y est fait mention de plusieurs entreprises (dont Microsoft et Cisco) ayant constaté des attaques potentiellement associées à la faille "Log4Shell".
Pour l'anecdote, on ne pourra s'empêcher de noter que les "menaces" mentionnées font majoritairement parties des adversaires historiques des États-Unis.
Pour un avenir plus safe, le rapport propose 19 recommandations plus ou moins générales pour prévenir d'autres bugs de cette ampleur, dont voici un résumé :
- Sensibiliser les développeurs aux pratiques de sécurité
- Surveiller la bibliothèque Log4j
- Améliorer l'écosystème logiciel en investissant par exemple dans les formations cyber pour les développeurs ou la sécurité des logiciels open source
- Impliquer les organisations gouvernementales dans la surveillance des applications à risque
Le comité alerte enfin sur le fait que la faille Log4j est devenue une "vulnérabilité endémique" dans les systèmes d'information, qui pourrait perdurer pendant 10 ans, voire plus.
Dans les faits, certaines entreprises risquent de rencontrer des difficultés pour mettre à jour la bibliothèque pour diverses raisons : mises à jour de livrables (il n'y a pas que le courrier qui a des difficultés à être livré parfois), multiples versions de Log4j utilisées dans différentes dépendances d'un projet (voyez l'arbre de dépendance d'un projet comme un plat de spaghettis collés qu'il faut démêler 🍝) et j'en passe et des meilleurs...
Le rapport, qui ne manque pas de touche politique, n'est certes pas rassurant mais propose des axes d'amélioration. Notons aussi que différentes livraisons du correctif ont eu lieu et devraient arrêter l'hémorragie pour l'instant (définitivement, on l'espère).
Pour l'heure et chez nous (si si je vous jure, on a un site dédié pour ça depuis le 19 janvier 1999 ! OK, je sors de ma grotte) le gouvernement français préconise d'utiliser au moins la version 2.17.1 pour Java 8 ou supérieur, 2.12.4 pour Java 7, et... rien pour les versions inférieures (Java 6... big up aux projets qui tournent encore sous cette version) !
À lire aussi sur Les Joies du Code :
- 💥 Ce site recense les meilleurs memes sur la faille Log4j
- 🔎 En eaux troubles chez Twitter, Elon Musk partage sa première revue de code avec les développeurs
- 😱 Top 20 des trucs qui font le plus peur aux développeurs
