Stratégie de remédiation de PTC
En ce qui concerne la remédiation d'Apache Log4j 2 CVE-2021-44228 et CVE 2021-45046, PTC recommande de supprimer la chaîne JNDILookup.class comme décrit dans la remédiation d'Apache. Comme le montrent les tests effectués par PTC jusqu'à cette date (à savoir entre le 10 décembre et le 15 décembre 2021), l'utilisation de cette méthode n'a pas eu d'effets négatifs. PTC n'a pas utilisé cette fonctionnalité de chargement dynamique dans ses produits. Cette remédiation devrait être à la fois efficace pour résoudre la vulnérabilité et à très faible risque pour ses produits. Si cette modification présente un risque, ce risque est limité au sous-système de journalisation des applications et les erreurs qui en résultent sont bien moins importantes que ne l'est l'exposition à une faille de sécurité. En attendant une certification officielle qui leur permettra de réduire leur exposition à ce problème critique, les clients peuvent, préventivement, remédier à cette faille de sécurité.
Dans la documentation PTC sur la remédiation, fournie ci-dessous, nous indiquerons clairement où est intégré Log4j 2 dans les applications tierces et comment remédier au problème. Dans le cas où des logiciels PTC n'utiliseraient pas Log4j 2, il est possible que des composants tiers l'aient intégré et qu'il soit donc nécessaire, de la même façon, de remédier à cette situation. Dans le cas où des logiciels PTC utiliseraient Log4j 2, nous fournirons les versions de correctifs nécessaires intégrant les versions mises à jour de Log4j 2. Toutefois, les clients ne doivent pas attendre ces correctifs. Ils doivent prendre immédiatement des mesures pour sécuriser leurs systèmes. Cette recommandation s'applique à toutes les installations de nos clients, y compris leurs systèmes de développement et de test, leurs systèmes de production, sans oublier leurs applications bureautiques, comme indiqué ci-dessous.
PTC a décidé de ne pas recommander l'autre option de remédiation qui consiste à utiliser les propriétés des systèmes pour désactiver la fonction. Selon nous, cette solution risque de mener à l'échec en faisant passer purement et simplement les propriétés dans les applications ou, pire, en les excluant potentiellement à l'avenir, ce qui peut ne pas protéger convenablement vos systèmes. Un bulletin daté du 15 décembre 2021 vient également de signaler l'inefficacité de cette méthode : https://www.lunasec.io/docs/blog/log4j-zero-day-mitigation-guide/#option-2-enable-formatmsgnolookups
Concernant la vulnérabilité CVE-2021-4041 (https://bugzilla.redhat.com/show_bug.cgi?id=2031667) d'Apache Log4j 1.x, postée le 14 décembre 2021, PTC s'investit activement afin de proposer pour chaque produit les mesures de remédiation requises. La méthode JMSAppender qui y est décrite produit un scénario similaire à la faille de sécurité du Log4j 2 où un attaquant utilise un JMS Broker contre un vecteur d'attaque JNDI/LDAP. Cette faille nécessite un accès administratif au système pour activer cette fonction, désactivée par défaut. La gravité résultante de ce CVE (Common Vulnerabilities and Exposures, une liste publique de failles de sécurité informatique) correspond à un risque moyen étant donné l'intervention nécessaire pour l'activer. Les clients doivent considérer les étapes de remédiation fournies pour ce CVE s'ils ont activé leur propre utilisation de cette fonction. PTC fournira davantage d'informations sur ce parcours de résolution des failles au fur et à mesure que des informations seront disponibles.