A critical vulnerability has been identified in the log4j2 library
In addition, we are aware of other vulnerabilities affecting log4j version 1.x
However, we invite you
(*) Message of ceki, author of log4j 1.x library : http://slf4j.org/log4shell.html
(**) Messages on Tomcat user mailing list : Mark Thomas on Sat, 11 Dec 2021 23:39:50 GMT, Mark Thomas on Mon, 13 Dec 2021 09:40:32 GMT
[Edit : 2021-12-12 15:10 - Post updated to include precision on vulnerability CVE-2021-4104]
[Edit : 2021-12-13 9:00 - Added link related to CVE-2021-4104]
Ressources annexes :
https://www.techsolvency.com/story-so-far/cve-2021-44228-log4j-log4shell/
https://www.docker.com/blog/apache-log4j-2-cve-2021-44228/
https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592
https://github.com/Cybereason/Logout4Shell
https://www.lunasec.io/docs/blog/log4j-zero-day-mitigation-guide/
La communication de ces liens ne saurait être une approbation de leurs contenus par Jalios. Ils sont fournis à titre d'information.
Merci pour toutes ces infos !
Pour information, jodconverter, utilisé pour la conversion des documents Office en PDF par le PDF Converter Plugin 5.6, n'est pas touché non plus (il n'utilise pas log4j d'après ce que j'ai vu).
Merci Pierre MORIN, j'aurais effectivement pu lister l'ensemble des produits Jalios. Notre analyse montre qu'à ce jour, aucun de nos produits n'est vulnérable à ces failles.
Merci Olivier Jaquemet , j'ai pu effectivement constater entre temps que ni le serveur Horizon (en JS), ni l'application JMobile ne semblent touchées.
Je n'ai pas le code source de l'application JDrive, mais je n'ai pas à vérifier grâce à votre dernier message. 😉
Un update sur les dernières vulnérabilités de Log4j ? :
(Ceux-là sont-il couverts par le commentaire "[Edit : 2022-01-19 - ajout de liens sur des vulnérabilités de log4j 1.x récemment identifiées et n'affectant pas plus les produits Jalios]" ? Si oui, merci, tout est OK alors.)
CVE-2022-23307
CVE-2020-9493 identified a deserialization issue that was present in Apache Chainsaw. Prior to Chainsaw V2.0 Chainsaw was a component of Apache Log4j 1.2.x where the same issue exists.
CVE-2022-23305
By design, the JDBCAppender in Log4j 1.2.x accepts an SQL statement as a configuration parameter where the values to be inserted are converters from PatternLayout. The message converter, %m, is likely to always be included. This allows attackers to manipulate the SQL by entering crafted strings into input fields or headers of an application that are logged allowing unintended SQL queries to be executed. Note this issue only affects Log4j 1.x when specifically configured to use the JDBCAppender, which is not the default. Beginning in version 2.0-beta8, the JDBCAppender was re-introduced with proper support for parameterized SQL queries and further customization over the columns written to in logs. Apache Log4j 1.2 reached end of life in August 2015. Users should upgrade to Log4j 2 as it addresses numerous other issues from the previous versions.
CVE-2022-23302
JMSSink in all versions of Log4j 1.x is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration or if the configuration references an LDAP service the attacker has access to. The attacker can provide a TopicConnectionFactoryBindingName configuration causing JMSSink to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-4104. Note this issue only affects Log4j 1.x when specifically configured to use JMSSink, which is not the default. Apache Log4j 1.2 reached end of life in August 2015. Users should upgrade to Log4j 2 as it addresses numerous other issues from the previous versions.
Par avance merci
Bonjour Emmanuel Buff
Je vous invite à relire le billet et notamment les mentions de mise à jour, ces vulnérabilités ne nous concerne pas non plus.
C'est ce que je viens de voir à l'instant, un paragraphe parcouru trop vite. Tout est indiqué et merci pour ce rapide retour 👍
Bonjour à tous,
Ce billet vient d'être mis à jour pour préciser l'information suivante :