Log4Shell sur elasticsearch : comment rapidement corriger la faille CVE-2021-44228 log4j ?

Tout le monde en parle parce que ça touche tout (d'où la photo qui fait peur !!).

Log4J c'est LA lib java qui était dans tous mes projets Java avant même que Maven ne vienne au secours de mes builds eclipse, les (vieux) développeurs java comprendront :).

Bref si vous avez le moindre elasticsearch, apache solr, confluence, jira ...., vous devez rapidement mettre à jour.

Ici on va faire notre part : simple et efficace.

Il n'y a pas de secret, mettre à jour votre soft reste la meilleure option.
Mais parce qu'on doit être rapide, on n'a pas forcément le temps de vérifier la compatibilité de la dernière version.

Comment corriger la faille log4shell sans mettre à jour son application (mitiger en fait) ?

formatMsgNoLookups=true

La méthode est ok pour elasticsearch >= 6.4.0 et >= 5.6.11.

Il faut ajouter l'option "-Dlog4j2.formatMsgNoLookups=true" à la JVM.

Concrêtement, sur un conteneur docker elasticsearch, ajouter la variable d'environnement ES_JAVA_OPTS=-Dlog4j2.formatMsgNoLookups=true.

Sur docker compose :

Image

Cette approche n'est pas suffisante pour la majorité des cas (hors elasticsearch) mais il semble que ce soit le cas pour elasticsearch (https://stackoverflow.com/a/70352511).

Liens

• Un excellent focus Elasticsearch : https://xeraa.net/blog/2021_mitigate-log4j2-log4shell-elasticsearch/
• La description de la faille par Palo Alto : https://unit42.paloaltonetworks.com/apache-log4j-vulnerability-cve-2021-44228/

Vérifiez la compatibilité

Si vous utilisez les élément suivant, vérifiez que vous êtes protégés, notamment les services basés sur Apache Lucene (tous sous Java) :

• Elasticpress (elasticsearch pour wordpress)
• Search api Solr (intégration apache solr pour drupal)
• OpensearchServer
• Apache Nutch
• Magento (si elasticsearch installé pour la recherche de produits dans le catalogue)
• ...