L’Apache Software Foundation (ASF) a déployé mardi de nouveaux correctifs pour contenir une faille d’exécution de code arbitraire dans Log4j qui pourrait être exploitée par des acteurs malveillants pour exécuter du code malveillant sur les systèmes concernés, ce qui en fait la cinquième faille de sécurité à découvrir dans l’outil dans l’espace d’un mois.

Suivi comme CVE-2021-44832, la vulnérabilité est classée 6,6 en gravité sur une échelle de 10 et affecte toutes les versions de la bibliothèque de journalisation de 2.0-alpha7 à 2.17.0 à l’exception de 2.3.2 et 2.12.4. Bien que les versions 1.x de Log4j ne soient pas affectées, il est recommandé aux utilisateurs de mettre à niveau vers Log4j 2.3.2 (pour Java 6), 2.12.4 (pour Java 7) ou 2.17.1 (pour Java 8 et versions ultérieures).

« Apache Log4j2 versions 2.0-beta7 à 2.17.0 (à l’exclusion des versions de correctifs de sécurité 2.3.2 et 2.12.4) sont vulnérables à une attaque d’exécution de code à distance (RCE) où un attaquant autorisé à modifier le fichier de configuration de journalisation peut construire un configuration à l’aide d’un appender JDBC avec une source de données référençant un URI JNDI qui peut exécuter du code à distance », l’ASF mentionné dans un avis. « Ce problème est résolu en limitant les noms de source de données JNDI au protocole Java dans les versions Log4j2 2.17.1, 2.12.4 et 2.3.2. »

Bien qu’aucun crédit n’ait été accordé par l’ASF pour ce problème, le chercheur en sécurité de Checkmarx Yaniv Nizry crédit réclamé pour avoir signalé la vulnérabilité à Apache le 27 décembre.

« La complexité de cette vulnérabilité est plus élevée que la CVE-2021-44228 d’origine car elle nécessite que l’attaquant ait le contrôle de la configuration », Nizry c’est noté. « Contrairement à Logback, dans Log4j, il existe une fonctionnalité permettant de charger un fichier de configuration à distance ou de configurer l’enregistreur via le code, de sorte qu’une exécution de code arbitraire peut être réalisée avec [an] Attaque MitM, entrée de l’utilisateur se retrouvant dans une variable de configuration vulnérable ou modification du fichier de configuration. »

Avec le dernier correctif, les mainteneurs du projet ont résolu un total de quatre problèmes dans Log4j depuis la découverte de la faille Log4Shell plus tôt ce mois-ci, sans parler d’une cinquième vulnérabilité affectant les versions Log4j 1.2 qui ne sera pas corrigée —

• CVE-2021-44228 (Score CVSS : 10.0) – Une vulnérabilité d’exécution de code à distance affectant les versions Log4j de 2.0-beta9 à 2.14.1 (Corrigé dans la version 2.15.0)
• CVE-2021-45046 (score CVSS : 9.0) – Une fuite d’informations et une vulnérabilité d’exécution de code à distance affectant les versions Log4j de 2.0-beta9 à 2.15.0, à l’exception de 2.12.2 (Corrigé dans la version 2.16.0)
• CVE-2021-45105 (Score CVSS : 7.5) – Une vulnérabilité de déni de service affectant les versions Log4j de 2.0-beta9 à 2.16.0 (Corrigé dans la version 2.17.0)
• CVE-2021-4104 (Score CVSS : 8.1) – Une faille de désérialisation non fiable affectant Log4j version 1.2 (Aucun correctif disponible ; Mise à niveau vers la version 2.17.1)

Le développement intervient également alors que les agences de renseignement de toute l’Australie, du Canada, de la Nouvelle-Zélande, du Royaume-Uni et des États-Unis ont publié un avertissement consultatif conjoint contre l’exploitation massive de plusieurs vulnérabilités dans la bibliothèque de logiciels Log4j d’Apache par des adversaires infâmes.