36319Fermer36321
ZephLe 12/12/2021 à 13:57
Quelque chose que je n'ai pas compris (je n'ai pas pris la peine de creuser non plus, mais quelqu'un qui connait log4j pourra peut-être y répondre) : les articles semblent sous-entendre qu'on peut exploiter la faille en insérant un lookup jndi ([code]Quelque chose que je n'ai pas compris (je n'ai pas pris la peine de creuser non plus, mais quelqu'un qui connait log4j pourra peut-être y répondre) : les articles semblent sous-entendre qu'on peut exploiter la faille en insérant un lookup jndi (${jndi:machin}) dans n'importe quoi qui se retrouvera loggé y compris un input utilisateur.

J'imagine que log4j fonctionne comme toutes les bibliothèques de logging du monde, donc avec des appels qui ressemblent à _logger.LogWarning("Invalid user input: {0}", userInput) dans lesquels le 1er argument est un template qui supporte un certain nombre de syntaxes spéciales pour y insérer du contenu dynamique (dont le fameux lookup JNDI qui pose problème). Mais cette interpolation ne s'active que dans le template (qui est supposé être une chaine fixe définie par le code), pas dans les autres arguments de la fonction. Du coup à moins d'avoir mal utilisé la bibliothèque et passé un input utilisateur comme 1er argument de la méthode, impossible d'exploiter la faille ? Dans le cas contraire et si tous les arguments sont interpolés, log4j serait une passoire qui ouvre grand la porte à toutes les injections de code possibles et imaginables, non ?