Réponse de GitHub à la faille critique Log4j

La faille de sécurité connue depuis le 9 décembre dans la bibliothèque de journalisation Log4j a également alerté l’équipe de sécurité de GitHub. En très peu de temps, la faille s’était retrouvée sur la liste officielle des vulnérabilités Common Vulnerabilities and Exposures sous la désignation CVE-2021-44228, car elle est considérée comme particulièrement critique au niveau international. La bibliothèque vulnérable est open source et très répandue, en particulier dans les applications Java.

L’équipe de sécurité de GitHub a analysé sa propre infrastructure et sa plateforme afin de détecter une éventuelle exposition aux attaques Log4jShell et a publié ses dernières conclusions dans un billet de blog. De plus, GitHub a publié un Security Advisory, avec des conseils de sécurité sur la manière dont la communauté peut vérifier la présence de la faille dans ses projets.

Selon l’équipe de sécurité, la vulnérabilité Log4j n’est accessible qu’aux utilisateurs authentifiés sur les serveurs GitHub Entreprise dans la configuration recommandée. Toutefois, si une instance est configurée différemment et exclut le mode privé, la vulnérabilité pourrait également être ouverte aux utilisateurs non authentifiés. Les propres instances sur les serveurs d’entreprise peuvent être sécurisées comme suit :

  1. Version patchée: La mise à jour vers une nouvelle version de GitHub Enterprise Server, qui contient déjà des modifications pour corriger la faille, permet de sécuriser ses propres instances. Les versions 3.3.1, 3.2.6, 3.1.14 et 3.0.22 sont concernées.
  2. Correctif à chaud: La mise à jour d’une instance existante avec un hotpatch est également une option et devrait être possible sans fenêtre de maintenance. Ceux qui choisissent cette méthode devraient suivre les instructions de hotpatch de GitHub.

Selon le billet de blog, l’équipe GitHub a pris des mesures à partir du 10 décembre afin de limiter l’impact potentiel sur GitHub.com et GitHub Enterprise Cloud. Concrètement, les données de télémétrie ont été examinées et une surveillance supplémentaire a été mise en place, mais selon l’équipe, aucune attaque réussie sur la vulnérabilité Log4j n’a encore été identifiée. L’entreprise poursuit ses investigations et sa surveillance, et prévoit de nouvelles mises à jour si d’autres points d’attaque sont découverts.

Lire aussi

Les anciennes versions de Log4j appartenant à la branche 1.x (qui n’est plus mise à jour, fin de vie) ne sont apparemment pas concernées par la faille actuelle mais sont connues pour d’autres vulnérabilités.

Ceux qui souhaitent vérifier la présence de la faille Log4j dans leur infrastructure peuvent se faire aider par des outils. Une possibilité serait par exemple le Log4JShell Bytecode Detector, qui se trouve sur GitHub dans le dépôt CodeShield. Étant donné qu’une analyse de la bibliothèque n’est pas triviale, de tels outils ne peuvent toutefois que soutenir. En règle générale, ils ne fournissent pas une détection à 100 % dans toutes les situations.

GitHub tient au courant toutes les personnes intéressées dans son blog sur la sécurité. La communication sur l’état de la situation sur le front Log4j dont il est question ici peut être lue dans l’entrée actuelle du blog. D’autres informations et mises à jour sont disponibles sur le site web du projet Log4j chez Apache. L’équipe Log4j y a également publié un guide de migration qui devrait aider à passer à une version corrigée de la librairie concernée.

[Update 15.12.2021 6:52 Uhr] Log4j 2.15 est également considéré comme sujet à des erreurs. Ce n’est qu’à partir de Log4j 2.16 que l’on est du côté de la sécurité, comme nous l’avons appris grâce à une remarque d’un lecteur.

Lire aussi