LOG4J est une bibliothèque de journalisation JAVA commune fournie par APACHE et utilisée dans de nombreux produits, tels que les produits JAVA ou les plates-formes de services web. Les produits XPLM utilisent les bibliothèques log4j directement ou indirectement dans le code. Le code critique est un problème de sécurité dans les bibliothèques log4j comme expliqué ici :
https://logging.apache.org/log4j/2.x/security.html
La stratégie de remédiation de XPLM est la suivante par catégories.
Catégorie 1 : Supprimer le fichier de classe critique des bibliothèques log4j existantes
Désactiver complètement la fonctionnalité critique de log4j
Une solution immédiate pour désactiver la fonctionnalité critique est de supprimer le fichier de classe critique des fichiers jar de log4j et des fichiers jar tiers accumulés. Le fichier suivant doit être supprimé dans les fichiers jar :
orgapache\\N-logging\Nlog4j\Ncore\Nlookup\NdiLookup.class
Les fichiers jar affectés sont les suivants :
Général log4j log4j-core*.jar version 2.x
Général log4j log4j *.jar version 2.x
Fichiers Jar affectés dans les produits XPLM
ECAD Integrate ivs-*-main.jar (plusieurs emplacements)
Instructions générales d'enlèvement à exécuter sur chaque pot :
1. Fermer l'intégration XPLM et les outils connectés, s'assurer que la plate-forme du connecteur n'est pas en cours d'exécution (pas d'icône dans la barre des tâches).
2. Allez dans les fichiers jar concernés, changez l'extension du fichier .jar en .zip.
3. Editer le zip : supprimer le fichier orgapache\logging\log4j\core\lookup\JndiLookup.class
4. Renommer .zip en .jar
La suppression de la classe n'a pas d'effets secondaires pour les intégrations, car la classe correspondante ne sera pas utilisée par les intégrations.
La fonctionnalité de recherche critique peut également être désactivée dans log4j par des paramètres d'environnement, mais cette solution de contournement fournie par Apache n'est pas sûre dans tous les cas.
SET LOG4J_FORMAT_MSG_NO_LOOKUPS=true
Ce paramètre doit être défini dans les scripts de démarrage des produits d'intégration XPLM et/ou dans une variable d'environnement du système pour désactiver la fonctionnalité critique. Assurez-vous que les systèmes sont redémarrés après les modifications.
Catégorie 2 : Remplacer log4j par la version 2.17 ou supérieure
La vulnérabilité a été corrigée dans les versions 2.17 ou supérieures de log4j. Les administrateurs doivent remplacer les bibliothèques log4j et ajuster tous les chemins de classe de démarrage et les scripts de commande pour JAVA.
Les correctifs pour les produits dédiés fournissent la bibliothèque log4j mise à jour et les paramètres de configuration associés dans les scripts de démarrage pour faciliter l'installation. Les correctifs suivants sont disponibles :
Catégorie 3 : versions du produit XPLM ou correctifs
À l'avenir, toutes les versions du produit XPLM contiendront une version 2.17 ou supérieure de log4j.
Si vous avez des questions ou si vous avez besoin d'aide pour appliquer les actions, veuillez contacter [email protected] y compris des informations :
- Nom du client et nom de la personne à contacter
- Produit XPLM utilisé, y compris la version et la dernière mise à jour
- Produits intégrés que vous utilisez et qui proviennent d'autres fournisseurs
Toutes les actions de remédiation du produit fournies par XPLM s'appliqueront aux versions actuelles et activement supportées du logiciel. Cependant, les étapes de remédiation pour ces versions seront similaires ou identiques aux versions antérieures qui utilisent Log4j v1 ou v2 et qui ne sont plus activement supportées par XPLM.
XPLM encourage vivement les clients utilisant des versions plus anciennes à prendre des mesures similaires pour protéger leur infrastructure et à ne pas supposer que les versions antérieures du logiciel ne sont pas affectées par les vulnérabilités divulguées à ce jour.