Êtes-vous protégé contre log4j CVE-2021-44228 si Java n'est pas installé ?

Question

J'ai beaucoup lu sur la gravité de ce problème et je comprends les options disponibles pour le localiser dans le code que notre entreprise produit et mettre à jour les serveurs qui utilisent des versions vulnérables.

Ce que je n'arrive pas à savoir, c'est si un serveur particulier n'a pas Java installé, c'est-à-dire si je me connecte en tant que root et que j'exécute java -version et que j'obtiens java: commande introuvable, ce serveur est-il totalement à l'abri de ce problème et puis-je passer au suivant?

Mon instinct initial était: pas de Java - pas de problème. Cependant, GitHub a publié une mise à jour pour leurs serveurs Enterprise en indiquant:

CRITIQUE: Une vulnérabilité d'exécution de code à distance dans la bibliothèque Log4j, identifiée sous le nom de CVE-2021-44228, a affecté toutes les versions de GitHub Enterprise Server antérieures à 3.3.1. La bibliothèque Log4j est utilisée dans un service open-source s'exécutant sur l'instance du serveur GitHub Enterprise. Cette vulnérabilité a été corrigée dans les versions 3.0.22, 3.1.14, 3.2.6 et 3.3.1 de GitHub Enterprise Server. Pour plus d'informations, veuillez consulter cet article sur le blog de GitHub.

Et pourtant, Java n'est pas installé sur leur serveur Enterprise.

Je pense que le service en cause doit être Java qui s'exécute dans un conteneur Docker. Donc, je pense que je dois prendre en compte Java sur la machine ou Java qui s'exécute dans un conteneur.

Y a-t-il d'autres manières cachées auxquelles je n'ai pas pensé par lesquelles ce processus log4j peut s'exécuter?

Answer 1

Log4j2 est une bibliothèque qui doit être utilisée par un processus java en cours d'exécution pour être vulnérable. Mais vous avez raison, vérifier si la commande java est installée sur la ligne de commande ne suffit pas.

Voici deux options (non destinées à être complètes), comment votre système pourrait toujours être vulnérable sans avoir la commande java disponible sur la ligne de commande.

• Java pourrait être téléchargé dans un répertoire sans ajouter la commande java ou le répertoire au PATH exécutable. En utilisant un script .bash (ou .bat) un processus java pointant vers la version de java téléchargée pourrait quand même être démarré. Mais lorsque le répertoire n'est pas ajouté au chemin, vous ne trouverez pas la commande java activée.
• Java pourrait fonctionner à l'intérieur d'un conteneur docker. la commande java ne serait disponible qu'à l'intérieur de votre conteneur docker mais pas visible de l'extérieur. Je ne suis pas sûr qu'une exploitation supplémentaire serait nécessaire pour sortir du conteneur ou si cela est facilement possible sans effort supplémentaire.

Answer 2

Je n'ai pas encore une réponse complète mais très définitivement NON vous n'êtes pas en sécurité même si Java n'est pas installé, et Docker n'est pas installé, et Java ne fonctionne pas dans la liste des processus, et Java ne figure pas dans vos listes d'applications installées par yum/apt.

Un cas évident auquel je n'avais pas pensé est lorsque Java est ajouté à une application en tant que JRE.

Un serveur de la plateforme Coverity que nous avons n'installe pas Java mais Java fonctionne par exemple ps -ax | grep java

/home/coverity/cov_platform-2021.9.0/jre/bin/java -Djava.awt.headless=true -Djdk.tls...

Déterminer si une version vulnérable de Log4j est incluse dans ce JRE est beaucoup plus difficile.

De plus, vérifier simplement la liste des processus n'est pas suffisant non plus. Dans ce cas, la liste des processus contenait java mais Java peut être exécuté uniquement lorsqu'il est déclenché par un autre processus par exemple cron, nginx, etc