Log4j, java et CVE-2021-44228 (log4shell)

Bonjour,

Intro

une faille dans la bibliothèque log4j (un composant java libre utilisé pour les logs) a été découverte la semaine dernière suite à un souci dans minecraft. La faille est assez sévère en partie parce que c’est assez trivial a exploiter, mais surtout de part les pratiques du monde java, à savoir de coller les libs avec le binaire, et d’oublier. La version impacté est la 2, la version 1 n’etant pas impacté à priori, ou pas de façon aussi importante.

Le compte rendu initial explique un peu le souci, et une analyse plus poussée a été aussi écrite dans la journée. En gros, c’est la combinaison de plusieurs comportements innocents en apparence quand ils sont pris séparément.

D’une part le fait de pouvoir rajouter des variables dans des chaines de format (avec %{xxx}), chose qui est utilisé via la configuration de log4j (donc sous le contrôle de l’admin et/ou du dev). Log4j a une configuration en XML, ou on peut vraiment aller finement dans les détails de ce qu’on loggue ou et comment.

Une autre fonction qui est importante pour la faille a été de rajouter le support de JNDI (une API java qui permet d’abstraire les requetes pour aller sur LDAP, DNS, NIS, ou un bus RMI/CORBA). Ça permet d’utiliser LDAP de manière transparente dans la chaine de format, pour par exemple configurer ça en partie via un serveur distant. Je ne pense pas que j’aurais lusage de ce genre de fonction, mais j’imagine dans un truc avec des milliers de programmes, ça peut avoir un usage, surtout si on part du principe que c’est via la config sous le contrôle de l’admin.

J’aimerais pointer que Java visait à une forme de transparence réseau au début (on peut critiquer Sun, mais je pense qu’ils ont eu la bonne idée trop tôt). RMI, c’est remote method invocation, c’est l’ancêtre d’un appel HTTP REST, ou le successeur des bons vieux RPC du monde Unix. Il y a eu des failles sur ça, et donc le fait de charger des classes via LDAP ou RMI est désactiver par défaut depuis 2/3 ans dans java.

Et enfin, la dernier fonction, le fait que log4j supporte les chaines de format comme printf le fait.
Avec du coup un remake des failles dans printf avec les chaines de format fournis par l’utilisateur.

Je détaille, parce qu’en cherchant sur le sujet, j’ai vu pas mal de gens critiquer les volontaires de log4j et c’est important de comprendre que le souci n’est pas d’avoir mis du code bugué, mais d’avoir mis des fonctions toutes raisonnables, sauf combinés.

Mais même si c’était un bug, les bugs, ça arrive. Un article récent sur la toxicité dans le libre montre que c’est une cause de burnout chez les devs, donc je pense que c’est important de ne pas oublier qu’il y a des humains qui tentent de faire de leur mieux derrière le libre.

Impact

J’en parle ici, parce que de ce que je voit, il y a potentiellement beaucoup de monde touché.

Comme j’ai dit, le monde java a tendance à embarquer les libs (vu que ça tourne partout), et mes collègues sont assez occupés sur ça depuis hier (entre les demandes en interne et les demandes clients). Je vais me concentrer sur les logiciels que des CHATONS pourraient avoir dans leur infras, vu que c’est grosso modo ce que j’ai regardé pour mon boulot.

Jenkins

Jenkins, logiciel bien connu de CI/CD, n’est pas impacté. Il y a un article de blog qui dit qu’une autre lib est utilisé. Mais il y a un certain nombre de plugin touchés, la plupart semblent obscurs, à part audit-log. Une fonction groovy est dispo pour tester ça, et la liste est sur le bugtracker de Jenkins.

Gerrit

Gerrit utilise log4j version 1. C’est normalement suffisant pour ne pas avoir de souci. La faille existe via un autre vecteur, mais ça requiert l’usage d’une configuration extrêmement spécifique, et ça ne permet pas d’exécuter de code. De ce que je vois, la communauté gerrit n’a d’article ni rien pour le moment. Et log4j 1 n’est plus maintenu depuis 6 ans, donc c’est pas terrible à un autre niveau.

Jitsi

Jitsi est plus ou moins impacté. Plus ou moins car il semble que 2 composants sont touchés, mais je n’ai pas déployé Jitsi, donc je ne sais pas si c’est des composants importants ou pas.

Elasticsearch (et forks), logstash

Visiblement, Elasticsearch en lui même n’est pas vulnérable (pour la partie execution de code, on peut toujours exfiltrer des variables d’environnement via le DNS). Certains autres produits de la boite qui peuvent ou pas être libres et qui peuvent ou pas venir avec le composant principal peuvent l’être. Je ne sais pas pour les forks, mais je suppose que c’est pareil.

Logstash est pleinement affecté, et doit être mis à jour.

Big blue button

BBB est en partie écrit en java (si j’en crois les stats github). Quel partie, je ne sais pas. Mais il semble que la bibliothèque sous jacente ne soit pas log4j, mais slf4j, la même que Jenkins, donc j’aurais tendance à dire « non vulnérable ». Pareil, si quelqu’un avec un BBB peut regarder, ça serait sympa.

Protections génériques contre la faille

En dehors de mettre à jour (ce qui implique des mises à jours), il y a des choses qui font que la faille ne va pas forcément toucher des CHATONS, ou qui vont limiter les exploitations les plus rapides

Avoir une JVM à jour

L’exploit public le plus utilisé se sert de JNDI et LDAP. C’est quelque chose qui est par défaut à « off » dans les JVM depuis 2017. Donc une JVM à jour suffit. Il faut comparer java -version avec les versions sur l’annonce. Attention, ça ne bloque que la partie facile. Il reste d’autres manières bien plus complexes d’exploiter la faille (et surtout qui dépendent des versions et des libs chargés, donc plus fragile et moins automatisable).

Bloquer le réseau

Je pense que si c’est possible, bloquer le réseau (soit via systemd, soit via iptables, ou via apparmor/selinux) permet de compliquer suffisamment la via d’un attaquant pour gagner du temps. Le risque n’est pas que quelqu’un passe 1 mois à attaquer un service mais plus qu’une vague d’attaque automatique soit mise en place pour miner du bitcoin (vu que c’est ce qui arrive sur les failles wordpress, jenkins, etc). Donc bloquer le réseau en sortie a tendance à suffire pour ce genre d’attaque.

J’ai fait ça pour les 2 services (zanata et gerrit) potentiellement vulnérables avant d’aller chercher les détails. Iptables a un module owner qui permet de filtrer en sortie de la machine par uid, ce qui permet d’éviter de tout casser. Mais les 2 utilisent log4j 1, donc ça devrait aller.

Retirer la classe vulnérable dans l’archive java

Je n’ai pas testé, mais visiblement, des gens proposent de retirer directement le bout de code qui pose souci via zip et rm. C’est à essayer en cas de dernier recours.Je n’ai pas de lien à donner, mais dans tout les cas, faire une copie avant de magouiller le soft me parait important.

Conclusion

Je pense qu’au moins pour les chatons, il n’y a pas de raison de trop s’affoler au contraire d’une entreprise moyenne avec une tonne de code java en interne (ou des logiciels proprio à mettre à jour), mais qu’on dort mieux après une vérif rapide de sa version de la JVM et des softs utilisés.

3 Likes

Alors je rajoute aussi à regarder:

  • signald, qui est vulnérable, cf ce commit, utilisé pour le bridge matrix.
  • papermc, un serveur minecraft libre (je suppose que des CHATONS peuvent héberger ça)
  • Guacamole. Je suppose que c’est plus rare de proposer ça comme service, mais je peux en voir l’utilité.

J’ai vu la liste sur reddit. J’ai aussi fait un tour sur awesome self-hosted, et y a rien qui m’a sauté aux yeux que j’aurais pu voir chez un CHATONS, à part Zimbra et Bluemind (à vérifier), et peut être aussi Yacy (en java). Et peut être Puppet, vu qu’un poste de blog en parle pour dire qu’un composant doit être mis à jour (mais je n’ai plus fait de puppet depuis longtemps, c’est devenu un chouia trop complexe pour moi, donc je sais pas si c’est encore utilisé pour des petites infras)

1 Like

Merci @misc !

Pendant que mes pâtes étaient en train de cuire, j’ai été faire un tour sur la liste des chatons, et en supposant que la liste est à jour et que je n’ai rien manqué, je n’ai rien vu de nouveau en Java à part Jitsi et BBB, déjà couvert plus haut.

11 minutes très utiles, merci :slight_smile:

une liste d’applications concernées

1 Like

pour la détection

pour celle et ceux qui ont des reverse proxy

pour le log4j une proposition qui m’ait remonté

tuer les paquets via le reverse proxy/WAF quand il y a des requêtes HTTP avec les headers HTTP le champs X-API-Version ou n’importe quel champs dans les headers en fait qui contiennent « jndi: » X-Api-Version: ${jndi:

${${env:${lower:J}}ndi:... avec les bonnes fermetures

Une liste des CVE

Je ne sais pas si il a une erreur dans ton post, le formatage est bizarre (genre il manque un bout ?).

Utiliser un WAF risque d’être un jeu de chat et de souris constant, vu que qu’un attaquant peut imbriquer les lookups. La doc sur le sujet parle par exemple de lower, mais il y a plein d’autres façons de construire le mot jdni (exemple, la version de java commence par « j », donc prendre la première lettre), surtout si tu arrives à exfiltrer les variables via une requête DNS au préalable.

Sinon, systemd permet de verrouiller les services par adresse IP. C’est sans doute plus simple qu’iptables ou nftables, surtout dans la précipitation.

Et pour les logiciels utilisant log4j et ayant une version récente ( > 2.10), une option est dispo pour désactiver les fameux lookups, le souci étant de trouver exactement la version quand c’est un binaire et qu’on connaît pas java (genre, ça doit traîner dans pom.xml ou build.gradle, mais mes connaissances du monde java s’arrêtent la pour aujourd’hui.)

Grand merci pour la veille :smiley: . {{ Ce serait bien de continuer à publier et documenter sur ce fil afin que tous les chatons puissent facilement en prendre connaissance. Et apporter leur observations, correctifs, même les temporaires }}

1 Like

Pour ce qui concerne les services de visio chatons basés sur jitsi, les mesures sont simples && classiques . :smile_cat:
https://github.com/jitsi/jitsi-videobridge/issues/1773 → « un simple apt update && apt upgrade vu qu’on utilise les repo fourni par jitsi. » dixit la team tech Hadoly qui a procédé à la mise à jour dès la publication de la maj.

1 Like

Je me permets de dire un grand merci pour cette veille techno et pour ce topic très détaillé (on en a parlé au boulot, mais c’est toujours un gros plus à avoir).
Pour celleux qui veulent s’amuser, on peut installer une petite gzip bomb via Nginx avec le code suivant : https://gist.github.com/shipilev/92e709a868f3d328b6636e1bfc21cf09

Très pratique surtout quand on a pas de Java :slight_smile: (ça peut faire ralentir les bots)

1 Like

Je m’aperçoit aussi que dans la liste, j’ai oublié de mentionner ovirt, et j’ai un peu honte de ça. Pour le moment, c’est en cours d’examen.

Pour Gerrit, les devs upstream confirment mon analyse, et il semble que le code de log4j 1 vulnérable ne soit que dans un sous module (JMSAppender) et que le lookup dangereux n’est fait que sur les chaines données par un admin dans la configuration. Autant dire que ça réduit franchement la portée si il faut avoir un accès en écriture à la config avant.

1 Like

Concernant BigBlueButton, l’équipe de développement a annoncé ici avoir réalisé un audit de leur code et affirme que bbb n’est pas vulnérable à CVE-2021-44228 (log4j).

Cependant, iels rappellent, mais pour d’autres raisons (fin de vie de ubuntu 16.04), qu’il est préférable de passer au moins à la version 2.3, voire directement à la rc 2.4 .

Toutefois, log4j-1.2 est employée dans l’image docker bbb-soffice. Cette image, construite localement, est employée pour containeurisé libreoffice à l’occasion du rendu des présentations. JndiLookup.class n’y est pas présente.

Ce dernier point a été vérifié sur l’instance martyre BigBlueButton Server 2.4-rc-7 bbb.tandemproject.fr par la petite équipe d’adminsys (avec laquelle je m’amuse bien, même si je ne comprends pas la moitié des échanges :upside_down_face: ).

1 Like

Attention slf4j est une interface au sens programmation. Il est possible que le code fasse des références à la bibliothèque slf4j et qu’il embarque également log4j2 qui est une implémentation et dans ce cas, le programme est peut-être vulnérable à la faille log4shell. Il faut faire un audit comme ça a été fait plus haut :slight_smile:

1 Like

Log4j une 2.16 a passer car

https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core

1 Like

Et une 2.17, à cause d’un bug de récursion infini.

1 Like