Si tu as une erreur affichée, tu es impacté
Sinon si tu n’as pas de message, tu es safe
À tes souhaits 🤧
Les conseils de mitigations sont pas ouf.
L’attaques en 2 étapes étaient le début, maintenant il a été trouvé qu’on peut mettre directement le base64 d’un jar, le serveur va directement éxecuter le contenu.
Le vrai fix, c’est de mettre a jour la dépendance, rien d’autre.
6 comments
En loggant jdni(‘localhost:8080’)
Si tu as une erreur affichée, tu es impacté
Sinon si tu n’as pas de message, tu es safe
À tes souhaits 🤧
Les conseils de mitigations sont pas ouf.
L’attaques en 2 étapes étaient le début, maintenant il a été trouvé qu’on peut mettre directement le base64 d’un jar, le serveur va directement éxecuter le contenu.
Le vrai fix, c’est de mettre a jour la dépendance, rien d’autre.
Update par rapport à mon premier [message](https://reddit.com/r/france/comments/retj2g/comment_détecter_et_corriger_la_vulnérabilité/ho9reou?context=3) : c’est `Logger.info(“TEST : $(jdni:ldap://127.0.0.1/foo)”):`
Je suis en version 1.X chez moi, on a pas l’air d’être impacté directement par la faille d’après ce qu’on en savait vendredi.
Je ne sais pas si les créateurs de ce site vont me lire un jour mais le texte de l’article manque cruellement de contraste.
En tout cas, merci pour les informations !
Tu passes à log4j 2.15 c’est le plus simple à mettre en œuvre.
L’exploit dépend aussi de la version du JRE/JDK utilisé.
Si tu as été touché, tu as du loguer dans tes logs un “jndi” par exemple