Résumé :

Comme vous l’avez peut-être vu dans les nouvelles du jeudi 9 décembre, un nouvel exploit Zero-Day a été signalé contre la populaire bibliothèque de journalisation Java Log4j2 qui peut permettre à un attaquant d’exécuter du code à distance. Cette vulnérabilité référencée sous le code CVE-2021-44228 a été signalée contre le fichier jar log4j-core qui a été corrigée dans Log4J v2.15.0.

CVE-2021-44228 est une vulnérabilité classée sous la note de gravité la plus élevée, soit 10 sur 10.

Quelles versions de Log4J sont concernées par cette faille de sécurité ?

Versions concernées :

• Apache Log4J versions 1.x : sous réserve de configuration particulière
• Apache Log4J versions 2.0 à 2.14.1

ARender est-il concerné par cette faille de sécurité ?

ARender V3 (3.1.x) :

Dans cette version, ARender utilise log4j-1.2.16 à la fois sur l’IHM et sur Rendition.

Comme log4j 1.x n’offre pas de mécanisme de recherche JNDI au niveau du message, il n’est pas affecté par CVE-2021-44228.

Cependant, log4j 1.x est fourni avec JMSAppender qui peut effectuer une recherche JNDI s’il est activé dans le fichier de configuration de log4j (log4j.properties ou log4j.xml). Ainsi, un attaquant pouvant écrire dans le fichier de configuration de l’application log4j peut effectuer une exécution de code à distance (RCE).

ARender V4 (4.x.x) :

D’autre part, dans ARender V4, ARender utilise une bibliothèque de journalisation différente pour l’interface utilisateur Web (IHM) et le rendu. Pour l’interface utilisateur Web, il utilise log4j-1.2.17 et pour le rendu, il utilise logback-1.2.3.

La rendition ARender est constituée de plusieurs microservices Spring Boot, utilisant par défaut la bibliothèque logback. Les bibliothèques log4j-to-slf4j et log4j-api incluent dans Spring Boot ne peuvent être exploités seuls. Après les premières analyses faites sur nos microservices, une dépendance log4j-core (2.12.1) a été trouvée dans le microservice TaskConversion (service permettant de faire les conversions de documents). Des tests ont été effectués sur ce service afin de reproduire la faille de sécurité et on en conclut que le service en question n’est pas affecté.

Comment résoudre cela ?

Par défaut, dans ARender V3, le fichier de configuration de log4j n’active pas le JMSAppender. Puisque log4j 1.x n’est pas vulnérable au niveau du message mais au niveau du fichier de configuration, si vous avez un fichier de configuration de log4j personnalisé qui remplace celui par défaut, nous recommandons que les fichiers de configuration soient protégés contre l’écriture. Ils doivent être en lecture seule pour tous les utilisateurs.

Comme nous l’avons évoqué plus haut, ARender V4 ne semble pas être affecté par la faille de sécurité. Cependant un des microservices possède une dépendance à la bibliothèque log4j-core, il est alors fortement recommandé que vous définissiez la propriété système log4j2.formatMsgNoLookups ou la variable d’environnement LOG4J_FORMAT_MSG_NO_LOOKUPS à true afin de mitiger la faille.

Remarque : Nous publierons un correctif sur la version ARender 4.7.x afin d’enlever la référence à cette dépendance (log4j-core).