RHSB-2021-009 Log4Shell - Exécution de code à distance - log4j (CVE-2021-44228) (CVE-2021-4104)

Résumé

Apache Log4j est une bibliothèque permettant d'intégrer une fonctionnalité de journalisation dans les applications basées Java. 

Une faille a été découverte dans Apache Log4j v2 (une mise à jour de Log4j). Cette vulnérabilité permet à un attaquant distant d'exécuter du code sur le serveur si le système consigne une valeur de chaîne contrôlée par l'attaquant via consultation du serveur Java Naming and Directory Interface™ (JNDI) Lightweight Directory Access Protocol (LDAP). Cette faille permet à un attaquant distant d'exécuter du code sur le système cible avec les mêmes privilèges que l'application Java qui a invoqué Apache Log4j v2. 

La première vulnérabilité est nommée CVE-2021-44228 et comporte un niveau de sévérité Critique.

Les produits suivants ne sont PAS concernés par cette faille et ont été explicitement listés ici pour le bénéfice de nos clients.

• Red Hat Enterprise Linux

• Gestion avancée des clusters Red Hat pour Kubernetes 

• Sécurité avancée des cluster Red Hat pour Kubernetes

• Plate-forme d'automatisation Red Hat Ansible (Engine et Tower)

• Red Hat Certificate System

• Red Hat Directory Server

• Red Hat Identity Management

• Red Hat CloudForms 

• Red Hat Update Infrastructure

• Red Hat Satellite

• Red Hat Ceph Storage

• Red Hat Gluster Storage

• Red Hat OpenShift Data Foundation

• Red Hat OpenStack Platform

• Red Hat Virtualization

• Red Hat Single Sign-On

Résumé technique

Une faille a été découverte dans la bibliothèque de journalisation Java Apache Log4j dans les versions allant de 2.0.0 à 2.15.0 (non incluse). Un attaquant distant qui peut contrôler les messages de journalisation ou les paramètres des messages de journal peut exécuter du code arbitraire sur le serveur via le point de terminaison LDAP JNDI. Reportez-vous à CVE-2021-44228 pour plus de détails.

Mitigation

Pour les versions 2.10 et ultérieures de Log4j :

• définir la propriété système log4j2.formatMsgNoLookups ou la variable d'environnement LOG4J_FORMAT_MSG_NO_LOOKUPS à true

Pour les versions de Log4j comprises entre 2.7 et 2.14.1 :

• tous les modèles PatternLayout peuvent être modifiés pour spécifier le convertisseur de message sous la forme %m{nolookups} au lieu de simplement %m

Pour les versions de Log4j comprises entre 2.0-beta9 et 2.10.0 :

• supprimer la classe JndiLookup du chemin de classe. Par exemple : 

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Sur OpenShift 4 et dans OpenShift Logging, l'atténuation ci-dessus peut être appliquée en suivant les étapes de cet article :https://access.redhat.com/solutions/6578421

Sur OpenShift 3.11, des mesures d'atténuation pour le composant Elasticsearch affecté peuvent être appliquées en suivant les étapes de cet article : https://access.redhat.com/solutions/6578441

Détails techniques

Une faille a été découverte dans la bibliothèque de journalisation Java Apache Log4j dans les versions allant de 2.0.0 à 2.15.0 (non incluse). Un attaquant distant qui peut contrôler les messages de journalisation ou les paramètres des messages de journal peut exécuter du code arbitraire sur le serveur via le point de terminaison LDAP JNDI.

Ce problème ne concerne que les versions de log4j comprises entre 2.0 et 2.14.1. Afin d’exploiter cette faille, cela requiert :

• Un point de terminaison accessible à distance avec n'importe quel protocole (HTTP, TCP, etc.) qui permet à un attaquant d'envoyer des données arbitraires,

• Une déclaration de journal dans le point final qui enregistre les données contrôlées par l'attaquant.

Impact sur les services cloud

L'impact de CVE-2021-44228 et des vulnérabilités connexes de log4j divulguées à ce jour a été évalué pour tous les services cloud.  Ceux qui ont été identifiés comme potentiellement concernés ont été traités immédiatement. L'utilisation de la composante vulnérable et l'exposition potentielle varient selon les services. Red Hat a appliqué des mesures d'atténuation (voir ci-dessus), des correctifs et, dans certains cas, a retiré le composant vulnérable afin de traiter le risque en temps opportun.

Red Hat continue de surveiller l'impact potentiel de ces vulnérabilités sur les services cloud de Red Hat et collabore avec des tiers, si nécessaire, afin de fournir une assurance à nos services.  D'autres communications seront émises en fonction des besoins.

Mises à jour pour les produits concernés

Il est fortement recommandé aux clients de Red Hat utilisant des versions affectées de ces produits Red Hat de les mettre à jour dès que les errata sont disponibles. Les clients sont invités à appliquer immédiatement les mises à jour disponibles et à activer les mesures d'atténuation qu'ils jugent appropriées.  

[1] Le lien "Avis/Mise à jour" sera ajouté une fois que les mises à jour seront mises en ligne.

Diagnostic

Un script de détection a été développé afin de déterminer si votre système est actuellement concerné par cette faille de sécurité. Pour vérifier la légitimité du script, vous pouvez télécharger la signature GPG détachée également. Les instructions sur la manière d'utiliser la signature GPG pour la vérification sont disponibles sur le portail client.

FAQ

Q : Devons-nous redémarrer un service ou une application après avoir appliqué des correctifs de sécurité ou des mesures d'atténuation ? Si oui, lesquelles ?  

R : Bien qu'il soit recommandé de redémarrer votre service ou votre application, cela dépend de la stratégie de déploiement de l'application, par exemple : 

• Dans les applications basées sur Java, oui, les serveurs d'application doivent être redémarrés après avoir appliqué le correctif de sécurité.

Q. Dans les produits Red Hat OpenShift (y compris OpenShift Logging), est-il nécessaire d'accepter les mises à jour dès qu'elles sont disponibles ? 

1. Pour en savoir plus sur le processus de mise à jour d'OpenShift Container Platform et d'OpenShift Logging, utilisez le guide suivant comme référence :

• Comprendre le service de mise à jour d'OpenShift

• Mise à jour de la journalisation d'OpenShift

Q : Les services comme ARO/OSD/ROSA sont-ils vulnérables ? 

R : Non, pour les raisons citées ici : 

Vulnérabilité d'Apache log4j2 à l'exécution de code à distance (RCE)

Q : Après avoir appliqué les mises à jour de Log4j v2 mentionnées ci-dessus, dois-je encore attendre la publication des Errata de sécurité de CVE-2021-45046, CVE-2021-45105 et CVE-2021-44832 ?

R : Non, vous ne devez pas attendre les nouvelles versions de CVE-2021-4504, CVE-2021-45105et CVE-2021-44832. Les deux CVE sont des problèmes d'impact de gravité MODÉRÉE. À moins que vous n'utilisiez un modèle de disposition par défaut avec recherche de contexte (par exemple, $${ctx:loginId}) dans la configuration de Log4J de votre produit (qui n'est pas configuré par défaut dans les produits Red Hat), vous n'êtes pas vulnérable à ces problèmes.

Q : Certains produits Red Hat fournissent Log4j v1. Les mises à jour mentionnées dans ce bulletin de sécurité corrigent-elles également la vulnérabilité de Log4j v1 ?

R : Log4j version 1 n'est pas affecté par CVE-2021-44228 (Log4Shell). Pour Log4j v1, il existe un problème distinct, CVE-2021-4104 (Log4j v1.x), dont l'impact est de gravité Modérée. Ce problème est différent du CVE-2021-44228 (Log4Shell). Log4j 1.2 est vulnérable à la désérialisation de données non fiables lorsque l'attaquant a accès en écriture à la configuration de Log4j ou est configuré pour utiliser JMSAppender avec des options spécifiques activées, ce qui n'est pas la configuration par défaut. Pour les produits Red Hat livrant Log4j v1, les permissions et la configuration par défaut définies sur Log4j v1 atténuent les effets de CVE-2021-4104. Veuillez consulter la page CVE (CVE-2021-4104) pour plus de détails. 

Références

• Injection de code à distance dans Log4j - Github 

• Vulnérabilités de sécurité d'Apache Log4j

• Log4Shell : Un exploit RCE 0-day a été découvert dans log4j2, un paquet de journalisation Java populaire