Ce week-end, une très importante faille – baptisée Log4Shell – a été découverte dans la bibliothèque de journalisation Apache log4j. On se trouve dans le pire scénario puisqu’elle permet d’exécuter du code arbitraire à distance, sans authentification. Comme avec Heartbleed, certains sites ont... fermé.
Vendredi, le CERT-FR publiait un bulletin sur cette brèche identifiée par le CVE 2021-44228. Pour vous donner une idée du niveau de « panique », elle se paye le luxe d’obtenir une note de 10/10 pour ce qui est de sa dangerosité. Les détails techniques sont donnés par Apache dans ce bulletin.
Le centre gouvernemental de veille, d’alerte et de réponse aux attaques informatiques rappelle de son côté qu’Apache log4j « est très souvent utilisée dans les projets de développement d'application Java/J2EE ainsi que par les éditeurs de solutions logicielles sur étagère basées sur Java/J2EE ».
Attention, ne pas utiliser Java ne suffit pas à considérer que vous êtes épargné, puisque cela peut être le cas de briques sous-jacente de votre architecture. Log4j est utilisé dans une large panoplie de frameworks : Apache Struts2, Solr, Druid, Flink… Elle peut donc se répandre comme une trainée de poudre.
Vous avez donc tout intérêt à vérifier ce qu'il en est dans votre cas. Des détecteurs ont bien évidemment été mis en ligne (ici ou là par exemple) maintenant que les prototypes d’exploitation sont publics.
Vite on se met à jour…
Selon Bleeping Computer, cette faille aurait été détectée par l’équipe de sécurité d’Alibaba Cloud et notifiée à Apache le 24 novembre. Des preuves de concept ont rapidement été mises en ligne et des exploitations ont bien évidemment été confirmées dans la foulée. Certains évoquent néanmoins une détection du problème dès 2016.
Toutes les versions de la bibliothèque sont concernées, à part la 2.15.0 qui vient de sortir et corrige justement la faille. Dans le cas des versions 1.x de Log4j, il y a une condition pour qu’elle soit exploitable : « la vulnérabilité n'existe que si le composant JMS Appender est configuré pour prendre en compte JNDI. Il s'agit donc d'une configuration très spécifique », explique le CERT-FR.
… à défaut des solutions de contournement
Il est évidemment plus que fortement recommandé d'utiliser la version 2.15.0 de log4j afin de se prémunir contre Log4Shell, mais si ce n’est pas possible des contournements sont possibles :
- Log4j versions 2.7.0 et ultérieures : « il est possible de se prémunir contre toute attaque en modifiant le format des évènements à journaliser avec la syntaxe %m{nolookups} pour les données qui seraient fournies par l'utilisateur. Cette modification impose de modifier le fichier de configuration de log4j pour produire une nouvelle version de l'application. Cela requiert donc d'effectuer de nouveau les étapes de validation technique et fonctionnelle avant le déploiement de cette nouvelle version »
- Log4j versions 2.10.0 et ultérieures : « il est également possible de se prémunir contre toute attaque en modifiant le paramètre de configuration log4j2.formatMsgNoLookups à la valeur true, par exemple lors du lancement de la machine virtuelle Java avec l'option -Dlog4j2.formatMsgNoLookups=true. Une autre alternative consiste à supprimer la classe JndiLookup dans le paramètre classpath pour éliminer le vecteur principal d'attaque (les chercheurs n'excluent pas l'existence d'un autre vecteur d'attaque) ».
Amazon Web Services propose de son côté un hotpatch, « à utiliser à vos risques et périls ». D’autres « techniques » ont été publiées, notamment Logout4Shell qui « utilise cette faille contre elle-même ». Stéphane Bortzmeyer pose la question de la légalité de cette manœuvre qui consiste à « pirater une machine pour la patcher ».
« Menace importante » pour la NSA, le Québec ferme des milliers de sites
Les réactions sont nombreuses, trop pour les détailler toutes ici. Rob Joyce, directeur de la cybersécurité à la NSA, explique néanmoins qu’il s’agit d’une « menace importante en raison de son inclusion généralisée dans les frameworks logiciels, même le GHIDRA de la NSA », un logiciel open source d'ingénierie inverse.
Le Québec a décidé de suspendre « en urgence » près de 4 000 sites et services gouvernementaux : « La balance des inconvénients faisait en sorte qu’on était mieux de fermer les systèmes et de s’assurer qu’ils étaient sécuritaires avant de les remettre disponibles », affirmait Éric Caire, ministre délégué à la Transformation numérique, comme le rapporte le Journal de Montréal. D’autres sites sont évidemment touchés, comme l’indique Motherboard : Minecraft, iCloud, Twitter, Steam…
De son côté, Cloudflare pense avoir été épargné : « Alors que nous utilisions des versions du logiciel comme décrit ci-dessus, grâce à notre rapidité de réponse et à notre approche de défense en profondeur, nous ne pensons pas que Cloudflare ait été compromis ». Comme a son habitude, le service a rapidement livré une analyse détaillée du problème et évoqué des tentatives capturées ici ou là afin de permettre leur identification.
On remet une pièce sur le débat de l’open source
Comme on pouvait s'y attendre, la découverte de Log4Shell a relancé la question du financement, du maintien et des vérifications des applications open source, qui sont parfois utilisées dans des projets d’envergure. C’est encore et toujours l’occasion de mettre en avant cet excellent dessin de xkcd :
Si dans le cas présent les développeurs semblent avoir été prompts à proposer une mise à jour, certains se demandent si cette « catastrophe » aurait pu être évitée avec une équipe plus conséquente. La question avait été posée avec Heartbleed par le passé et se posera encore très certainement à l’avenir.
Nous avions récemment interrogé Lancelot Pecquet, maître de conférences à l’université de Poitiers, afin de savoir si l’« électrochoc » Heartbleed avait fait bouger les choses dans la durée : « mon impression et mon observation : ça n’a pas changé grand-chose […] car les gens sont très pressés de sortir la nouvelle fonctionnalité ».
S’il en fallait une confirmation, elle vient de tomber.
Nadim Kobeissi a publié un billet de blog sur la question des « mainteneurs » des projets open source, en s’appuyant sur la douloureuse expérience Log4Shell. Il en profite pour rappeler deux « vérités gênantes ».
Il explique ainsi que, « comme beaucoup d’autres projets open source, Log4j est assez petit pour devenir facilement remplaçable en interne à partir du moment où les entreprises commencent à se sentir obligées de dépenser de l’argent pour cela ». S’appuyant sur ce tweet expliquant que la faille viendrait d’une fonctionnalité que les développeurs voulaient supprimer, mais qui a été conservée pour des raisons de compatibilité, Kobeissi ajoute qu’un « grand nombre » de problèmes peut être résolu en réduisant le nombre de fonctionnalités à maintenir (pour se concentrer sur l’essentiel) plutôt qu’en les augmentant, parfois pour de mauvaises raisons.
Les développeurs ont été prompts à réagir
Volkan Yazıcı d’Apache Software Foundation, en rajoute une couche : « Les mainteneurs de Log4j ont travaillé sans sommeil sur des mesures d'atténuation ; correctifs, docs, CVE, réponses aux demandes de renseignements, etc. Pourtant, rien n'empêche les gens de nous critiquer, pour un travail pour lequel nous ne sommes pas payés, pour une fonctionnalité que nous n'aimons pas tous, mais que nous devions conserver en raison de problèmes de compatibilité ascendante ». La question peut être étendue à bien d’autres services…
VideoLan cite l’exemple de FFmpeg. Cédric Champeau, qui travaille pour Oracle Labs ajoute que la question du salaire ne fait pas tout : « C'est un peu ennuyeux de voir comment les gens pensent que le financement d'OSS [Open-Source Software, ndlr] aurait évité le problème avec log4j. Ce ne serait pas le cas. Nous écrivons tous des bugs, le plus important est le processus pour les corriger et la facilité de mise à jour. Dans ce cas, bien qu'ils n'aient pas été payés, les mainteneurs de log4j ont fait un excellent travail ».
