Log4j 2.15 n'est pas étanche : Apache publie un deuxième correctif d'urgence

Le correctif d'urgence pour la fameuse vulnérabilité de la bibliothèque Java Log4j n'est pas infaillible. L'Apache Software Foundation publie une nouvelle version pour corriger la vulnérabilité une fois pour toutes.

Une vulnérabilité dans une bibliothèque très populaire pour Java secoue le paysage informatique mondial. On estime que la bibliothèque existe dans la plupart des environnements d'entreprise.

Log4j est principalement utilisé pour la journalisation. Les événements dans les applications peuvent être enregistrés avec des notes. Pensez à une impression des informations de connexion après une tentative de connexion. Ou, dans le cas d'une application Web en Java, le nom du navigateur auquel un utilisateur essaie de se connecter.

Ces derniers exemples sont courants. Dans les deux cas, un utilisateur externe influence le journal généré par Log4j. Il est possible d'abuser de cette influence. Les journaux de toute version de Log4j entre le 13 septembre 2013 et le 5 décembre 2021 peuvent demander aux applications Java d'exécuter le code à partir d'un serveur distant sur un appareil local.

Depuis 2013, Log4j traite une API : JNDI, ou Java Naming and Directory Interface. L'ajout de JNDI permet à une application Java d'exécuter du code à partir d'un serveur distant sur un appareil local. Les programmeurs instruisent en ajoutant une seule ligne de détails sur le serveur distant dans une application.

Le problème est que les programmeurs ne sont pas les seuls à pouvoir ajouter la règle aux applications. Supposons que Log4j enregistre les noms d'utilisateur des tentatives de connexion. Lorsque quelqu'un entre la ligne susmentionnée dans le champ du nom d'utilisateur, Log4j exécute la ligne et l'application Java interprète une commande pour exécuter le code sur le serveur spécifié. Il en va de même pour les cas où Log4j enregistre une requête HTTPS. Si vous modifiez un nom de navigateur sur la ligne, Log4j exécute la ligne, lui demandant indirectement d'exécuter le code comme vous le souhaitez.

Le patch d'urgence peut également être dangereux

Le 9 décembre, la vulnérabilité a été révélée à grande échelle. L'Apache Software Foundation, développeur de Log4j, a publié un correctif d'urgence (2.15) pour corriger la vulnérabilité. Depuis lors, les éditeurs de logiciels ont eu pour priorité absolue de traiter la version 2.15 et de fournir un correctif aux organisations.

Cependant, l'organisation de sécurité LunaSec déclare que le patch n'est pas complètement étanche. Il reste possible d'ajuster un paramètre et de faire exécuter des commandes JNDI journalisées.

Remarque : le paramètre correspondant doit être ajusté manuellement, afin que les variantes non modifiées de 2.15 soient effectivement sûres. Néanmoins, Luna Sec recommande aux fournisseurs et aux organisations de mettre à jour Log4j 2.16. 2.16 a été publié par Apache Software Foundation en réponse à LunaSec. La nouvelle version supprime complètement le paramètre vulnérable, ce qui rend impossible la création de conditions d'abus.