January 2022 - reload4j - mailman3.qos.ch

Release of relaod4j version 1.2.18.3
by Ceki Gülcü 24 Jan '22

24 Jan '22

Hello all, Details at https://reload4j.qos.ch/news.html With this release all known vulnerabilities in log4j 1.x have been fixed. -- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch

1 0

Secure XML Parser config?
by Bernd Eckenfels 24 Jan '22

24 Jan '22

Thanks a lot for forking the project. I noticed there is another known “open issue” which has no CVE assigned, but given that the other CVEs expect untrusted config entries, it might be in scope as well? Apache claims that the XML parser is vulnerable to external includes (xxe, billion laughters, ssrf). Should we enable secure processing and restrict remote protocols? If so.. should we do it unconditional or with a system property in case someone used really an external entity? >From the website: Other issues of note Log4j 1 doesn't restrict DTD entities in log4j.xml. Users should be careful to ensure any entities specified are correct and secure. BTW I mentioned on Twitter the RedHat backports, it looks like all of them are addressed in reload4j (some slightly different), they can be seen here for example https://git.centos.org/rpms/log4j/commits/c7 -- http://bernd.eckenfels.net

3 2

Release of reload4j version 1.2.18.2
by Ceki Gülcü 21 Jan '22

21 Jan '22

Hello all, I am very happy to announce the immediate availability of reload4j version 1.2.18.2. It is intended as a drop-in replacement for log4j version 1.2.17. By drop in, we mean the replacement of log4j.jar with reload4j.jar in your build with no source code changes in .java files being necessary. Reload4j has the following Maven coordinates: <dependency> <groupId>ch.qos.reload4j</groupId> <artifactId>reload4j</artifactId> <version>1.2.18.2</version> </dependency> Reload4j was built using Java 8 but targets Java 1.5. Version 1.2.8.2 corrects the following issues: The unit tests were updated but no actual code was changed except for the removal of NTEventAppender and the correction of the following issues: - Standardize and sanitize the build - CVE-2021-4104 (JMSAppender) - fixed in 1.2.18.0 by hardening - CVE-2022-23302 (JMSSink) - fixed in 1.2.18.1 by hardening - CVE-2019-17571 (SocketServer) - fixed in 1.2.18.0 by hardening - CVE-2020-9493 CVE-2022-23307 (Chainsaw) - fixed in 1.2.18.1 by hardening - CVE-2022-23305 (JDBCAppender) - fixed in 1.2.18.1 by hardening - broken MDC in newer JDKs - fixed in 1.2.18.0 Thanks to the remarkable work of Vladimir Sitnikov, JDBCAppender now interprets the SQL expression on the fly so as to insert new events using PreparedStartement instances. Note that the table column types are restricted to those types compatible with Java's String. Project web-site: https://reload4j.qos.ch/ Source repository: https://github.com/qos-ch/reload4j With release 1.2.18.2 we have addressed the most pressing issues regarding log4j 1.x vulnerabilities. As both log4j 1.x and reload4j do *not* offer a message lookup mechanism, they did not suffer from the notorious log4shell vulnerability. Donations and sponsorship You can also support SLF4J/logback/reload4j projects via donations and sponsorship. We thank our current supporters and sponsors for their continued contributions. Sponsorship link: https://github.com/sponsors/qos-ch?o=esb Announcement mailing list: You can receive SLF4J/logback/reload4j related announcements by subscribing QOS.ch announce list, please visit the following URL. http://www.qos.ch/mailman/listinfo/announce Enjoy, -- Ceki Gülcü

1 0

Switching from branch_1.2.18 to master
by Ceki Gülcü 21 Jan '22

21 Jan '22

Hello all, Are there any objection to switching from branch_1_2_18 to master as the principal development branch from now on? -- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch

2 1

the jdbc_cve branch
by Ceki Gülcü 21 Jan '22

21 Jan '22

Hi Vladimir, I am still studying PR 26. In the mean time, I have created a jdbc_cve branch in qos-ch/reload4j repo based on PR 26. Here is the link: https://github.com/qos-ch/reload4j/tree/jdbc_cve Here are changes so far: 1) reformat using javaConventions.xml 2) JdbcPatterParser is created only once in JdbcAppender.activateOptions and then reused. 3) Modified JdbcPatternParserTest to make them a bit easier to follow, at least for me I think point 2) is quote useful. Anyway, more later. -- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch

2 3

PR #26
by Ceki Gülcü 20 Jan '22

20 Jan '22

Hi Vladimir, FYI, just started studying PR 26 now. -- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch

1 0

Release of reload4j version 1.2.18.1
by Ceki Gülcü 19 Jan '22

19 Jan '22

Hello all, I am very happy to announce the immediate availability of reload4j version 1.2.18.1. It is intended as a drop-in replacement for log4j version 1.2.17. By drop in, we mean the replacement of log4j.jar with reload4j.jar in your build with no source code changes in .java files being necessary. Reload4j has the following Maven coordinates: <dependency> <groupId>ch.qos.reload4j</groupId> <artifactId>reload4j</artifactId> <version>1.2.18.1</version> </dependency> Reload4j was built using Java 8 but targets Java 1.5. Version 1.2.8.0 and 1.2.18.1 correct the following issues: The unit tests were updated but no actual code was changed except for the removal of NTEventAppender and the correction of the following issues: - Standardize and sanitize the build - CVE-2021-4104 (JMSAppender) - fixed in 1.2.18.0 by hardening - CVE-2022-23302 (JMSSink) - fixed in 1.2.18.1 by hardening - CVE-2019-17571 (SocketServer) - fixed in 1.2.18.0 by hardening - CVE-2020-9493 CVE-2022-23307 (Chainsaw) - fixed in 1.2.18.1 by hardening - CVE-2022-23305 (JDBCAppender) - fixed in 1.2.18.1 by *removal* - broken MDC in newer JDKs - fixed in 1.2.18.0 In the absence of a robust and well tested countermeasure, JDBCAppender has been removed to prevent SQL injection attacks. We have a proposed countermeasure which may yet salvage JDBCAppender. https://github.com/qos-ch/reload4j/pull/26 Project web-site: https://reload4j.qos.ch/ Source repository: https://github.com/qos-ch/reload4j With release 1.2.18.0 and 1.2.18.1 we have addressed the most pressing issues regarding log4j 1.x vulnerabilities. As both log4j 1.x and reload4j do *not* offer a message lookup mechanism, they did not suffer from the notorious log4shell vulnerability. Donations and sponsorship You can also support SLF4J/logback/reload4j projects via donations and sponsorship. We thank our current supporters and sponsors for their continued contributions. Sponsorship link: https://github.com/sponsors/qos-ch?o=esb Announcement mailing list: You can receive SLF4J/logback/reload4j related announcements by subscribing QOS.ch announce list, please visit the following URL. http://www.qos.ch/mailman/listinfo/announce Enjoy, -- Ceki Gülcü

1 0

SQL injection problem in JDBCAppender
by Ceki Gülcü 19 Jan '22

19 Jan '22

Hi All, JDBCAppender uses simple strings instead of java.sql.Statement to talk to the database. This creates a vulnerability point for SQL injection attacks. Fixing this vulnerability in JDBCAppender (a rarely used component) in a backward compatible way would be a lot of work for very little or no benefit. S such, I propose to remove JDBCAppender from reload4j with no replacement. Any objections? -- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch

3 9

state of reload4j
by Ceki Gülcü 19 Jan '22

19 Jan '22

Hello all, Except the SQL injection vulnerabilities in JDBCAppender (see , all known CVEs against log4j 1.x, including the recent ones, have been fixed in git. As I write this, Vladimir is working to fix JDBCAppender. -- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch

1 0

Indentation issues
by Ceki Gülcü 15 Jan '22

15 Jan '22

Hello all, In order to facilitate collaboration, I propose to use the Java formatting convention as proposed by Eclipse as the "javaConvention". According to my initial investigation, Intellij IDEA's implementation of the default formatting scheme differs from that offered by the Eclipse default quite a bit. I copied the relevant javaConventions.xml file into the reload4j repository [1]. The good news is that Intellij can import javaConventions.xml without trouble. The bad news is that Intellij's and Eclipse's interpretation of this formatting specification differ slightly. Fortunately, the difference relates to Javadoc text and stabilizes after a while. By stabilizes, I mean that formatting in Eclipse and Intellij converge into something which does not change even after repeated formatting by one or the other tools. Comments welcome. [1] https://github.com/qos-ch/reload4j/blob/branch_1.2.18/javaConventions.xml -- Ceki Gülcü Sponsoring SLF4J/logback/reload4j at https://github.com/sponsors/qos-ch

2 1