reload4j is a drop-in replacement for log4j 1.2.17

This PR goes on top of #12, so I suggest merging #12 first or just updating branch_1.2.18 to b04ec2b89b3b4b1575ec7e7e02372c900d2a573e which includes both PRs.

Our customer has concerns about the log4j vulnerabilities, we ran an activity and replaced all the log4j occurrences with the reload4j and those are working fine. But unfortunately we've some components like ( elastic-search/zookeeper/logstash ) and their binaries are using the log4j-1.2.16/17 rev. (zookeeper) and log4j-core-2.16.x/log4j-core-2.11.x (elastic-search/logstash). We successfully upgraded the elastic-search/logstash log4j version to log4j-core-2.17.1 ( by placing the higher version jars ) in lib directory but when we tried the same with zookeeper by replacing the log4j-1.2.16 with reload4j directly in lib and starts the zookeeper it throws the following exception:

tail: /var/seamless/log/zookeeper/init.out: file truncated Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/log4j/jmx/HierarchyDynamicMBean at org.apache.zookeeper.jmx.ManagedUtil.registerLog4jMBeans(ManagedUtil.java:50) at org.apache.zookeeper.server.ZooKeeperServerMain.initializeAndRun(ZooKeeperServerMain.java:74) at org.apache.zookeeper.server.ZooKeeperServerMain.main(ZooKeeperServerMain.java:52) at org.apache.zookeeper.server.quorum.QuorumPeerMain.initializeAndRun(QuorumPeerMain.java:116) at org.apache.zookeeper.server.quorum.QuorumPeerMain.main(QuorumPeerMain.java:78) Caused by: java.lang.ClassNotFoundException: org.apache.log4j.jmx.HierarchyDynamicMBean at java.net.URLClassLoader.findClass(URLClassLoader.java:381) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ... 5 more

reload4j doesn't include the HierarchyDynamicMBean.class which causing this issue. Can someone please guide how we can fix this?

Thanks

When I try to execute the build locally I get the following error:

[ERROR] Failures:
[ERROR]   TestLogMF.testDebugDouble:458 expected:<Iteration 3[,]142> but was:<Iteration 3[.]142>
[ERROR]   TestLogMF.testDebugFloat:446 expected:<Iteration 3[,]142> but was:<Iteration 3[.]142>
[ERROR]   TestLogMF.testInfoDouble:702 expected:<Iteration 3[,]142> but was:<Iteration 3[.]142>
[ERROR]   TestLogMF.testInfoFloat:690 expected:<Iteration 3[,]142> but was:<Iteration 3[.]142>
[ERROR]   TestLogMF.testTraceDouble:249 expected:<Iteration 3[,]14> but was:<Iteration 3[.]14>
[ERROR]   TestLogMF.testTraceFloat:235 expected:<Iteration 3[,]14> but was:<Iteration 3[.]14>

I suppose this is a localization issue in the test case.

reload4j has near full Reproducible Build: https://github.com/jvm-repo-rebuild/reproducible-central/blob/master/content/ch/qos/reload4j/README.md

but there is only one strange difference:

├── META-INF/MANIFEST.MF
│ @@ -2,15 +2,14 @@

│  Implementation-Vendor: QOS.CH Sarl (Switzerland)

│ -Originally-Created-By: Apache Maven Bundle Plugin 5.1.4

│  Export-Package: org.apache.log4j;version="1.2.22";uses:="org.apache.lo

how was this Originally-Created-By field injected in published binaries? Should the rebuild script do more than just mvn package to get this field injected? (I did not see any profile for that in project's pom.xml)

I downloaded reload4j 1.2.18.4 from Maven Central and executed logpresso [1] on it via

log4j2-scan --scan-log4j1 reload4j-1.2.18.4.jar

I get the following output:

[?] Found CVE-2021-4104  (log4j 1.2) vulnerability in C:\Users\xxx\Downloads\reload4j\reload4j-1.2.18.4.jar, log4j N/A

Scanned 0 directories and 1 files
Found 0 vulnerable files
Found 1 potentially vulnerable files
Found 0 mitigated files
Completed in 0.01 seconds

I don't know how logpresso actually works to identify the issue. But as the intention of reload4j is to fix CVE-2021-4104, there seems to be some inconsistency. Not sure if the ticket is placed correctly here or if it should be opened in the logpresso repository. Any insights would be helpful to get a consistent view on the fix provided via reload4j to avoid confusions.

[1] https://github.com/logpresso/CVE-2021-44228-Scanner

We used the scanning platform to scan the latest 1.2.19 version of reload4j and found the following CRITICAL vulnerabilities

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. CWE-502 Deserialization of Untrusted Data

CVSSv2: Base Score: HIGH (10.0) Vector: /AV:N/AC:L/Au:N/C:C/I:C/A:C CVSSv3: Base Score: CRITICAL (9.8) Vector: /AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

For details, see https://nvd.nist.gov/vuln/detail/CVE-2022-23307

Thanks all for work in hardening this. I've been testing reload4j and it's very nice that it is a simple drop-in replacement - it works great.

I note your statement that this is meant "to fix most pressing security issues. It is intended as a drop-in replacement for log4j version 1.2.17". I also read the comments about the Apache Software Foundation still considering log4j v1 as end of life. But I do note that SLF4J is now also supporting reload4J.

With the recent log4jv2 issues the spot-light has been placed on all logging systems and our security team are not happy that slf4j v1 is end of life. If we go to the security team and recommend replacing our existing log4jv1 JARs with reload4j I know what they will ask next.

Whilst I realise that, like most open-source, you probably do this in your spare time, would it be possible to clarify on the reload4j web site future plans. Is this still end-of-life, just a one shot replacement for log4jv1? Or will it now be a maintained (if needed) fork going forward - so no-longer end of life?

I do realise this is "how long is a piece of string" question but just some clarity on the website would be very useful.

Dear @qos-ch team,

All websites do not have updated of CVE-2018-8088 situation:

• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8088
• https://www.google.com/search?q=CVE-2018-8088

The problem was that you did not want to create a build in 1.7.x with the fix! It has been fixed in 1.7.26 (stable).

And 1.8.0-beta4 (not 1.8.0-beta2).

I think that today, you understand the problem of vulnerabilities / CVEs.

Thanks in advance.

Once i replace log4j1.x with reload4j, the application is unable to parse ang log4j.xml file giving the below exception. log4j:ERROR Failed to parse XML file. Missing DocumentBuilderFactory.setFeature() method?

java.lang.AbstractMethodError: javax.xml.parsers.DocumentBuilderFactory.setFeature(Ljava/lang/String;Z)V

at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:809)

at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:728)

at org.apache.log4j.helpers.OptionConverter.selectAndConfigure(OptionConverter.java:504)

at org.apache.log4j.LogManager.<clinit>(LogManager.java:119)

at org.apache.log4j.Logger.getLogger(Logger.java:101)

at org.apache.commons.logging.impl.Log4JLogger.getLogger(Log4JLogger.java:229)

at org.apache.commons.logging.impl.Log4JLogger.<init>(Log4JLogger.java:65)

at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)

at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)

at java.lang.reflect.Constructor.newInstance(Constructor.java:423)

at org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:529)

at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:235)

at org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:209)

at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:351)

at org.springframework.context.support.AbstractApplicationContext.<init>(AbstractApplicationContext.java:130)

at org.springframework.context.support.AbstractApplicationContext.<init>(AbstractApplicationContext.java:158)

at org.springframework.context.support.AbstractRefreshableApplicationContext.<init>(AbstractRefreshableApplicationContext.java:67)

at org.springframework.context.support.AbstractXmlApplicationContext.<init>(AbstractXmlApplicationContext.java:49)

at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:84)

at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:72)

Actually, it is broken since log4j:log4j:1.2.15 and above.

The problem is that, due to error in the generated META-INF/MANIFEST.MF , it is not possible to determine the version of log4j / reload4j programatically. This is due to an invalide Name: entry in the manifest.

This is a problem because it is then difficult to log, or access the reload4j version from code (for example, to check if you let the CVEs behind..)

• version detection works with: Name: org/apache/log4j/
• but is broken with the current: Name: org.apache.log4j

I'm not sure if I can make a pull request on reload4j, put the following git diff fixes the problem for me:

diff --git a/pom.xml b/pom.xml
index 1f54ec10..579cedc5 100644
--- a/pom.xml
+++ b/pom.xml
@@ -202,11 +202,19 @@
         <version>${maven-jar-plugin.version}</version>
         <configuration>
           <archive>
+            <manifest>
+              <addDefaultImplementationEntries>true</addDefaultImplementationEntries>
+            </manifest>
             <manifestEntries>
               <Multi-Release>true</Multi-Release>
               <X-Compile-Source-JDK>${maven.compiler.source}</X-Compile-Source-JDK>
               <X-Compile-Target-JDK>${maven.compiler.target}</X-Compile-Target-JDK>
             </manifestEntries>
+            <manifestSections>
+              <manifestSection>
+                <name>org/apache/log4j/</name>
+              </manifestSection>
+            </manifestSections>
             <manifestFile>${project.build.outputDirectory}/META-INF/MANIFEST.MF</manifestFile>
           </archive>
         </configuration>

Sample code for programatically acessing the version (as for other maven artifacts), but only works with a built jar:

	@Test
	public void testLog4jVersion() {
		String implementationVersion = org.apache.log4j.PatternLayout.class.getPackage().getImplementationVersion();
		LOGGER.warn("log4j.version="+implementationVersion);
		assertNotNull(implementationVersion);
	}

Certain older DocumentBuilderFactory implementations lack the setFeature function. This causes an AbstractMethodError method to be thrown in org.apache.log4j.xml.DOMConfigurator.doConfigure(ParseAction, LoggerRepository)

Instead of letting the user identify the issue, better to catch and report this

If the Java version string doesn't include a decimal point, reload4j incorrectly identifies it as Java 1. The initial version of each major release no longer includes a decimal point (since around Java 10 or 11), so reload4j incorrectly identifies these as Java 1 (circa 1995).

|  Welcome to JShell -- Version 19
|  For an introduction type: /help intro

jshell> System.getProperty("java.version")
$1 ==> "19"

jshell> org.apache.log4j.helpers.Loader.isJava1()
$2 ==> true

The simplest fix would be to make isJava1() always return false, since the reload4j website indicates that build targets Java 1.5, so the classfiles won't even work on Java 1.

Hi all,

we have prepared the Initial Integration of reload4j into Google OSS-Fuzz which will provide more security for your project.

Why do you need Fuzzing? The Code Intelligence JVM fuzzer Jazzer has already found hundreds of bugs in open source projects including for example OpenJDK, Protobuf or jsoup. Fuzzing proved to be very effective having no false positives. It provides a crashing input which helps you to reproduce and debug any finding easily. The integration of your project into the OSS-Fuzz platform will enable continuous fuzzing of your project by Jazzer.

What do you need to do? The integration requires the maintainer or one established project commiter to deal with the bug reports.

You need to create or provide one email address that is associated with a google account as per here. When a bug is found, you will receive an email that will provide you with access to ClusterFuzz, crash reports, code coverage reports and fuzzer statistics. More than 1 person can be included.

How Code Intelligence can support? We will continue to add more fuzz targets to improve code coverage over time. Furthermore, we are permanently enhancing fuzzing technologies by developing new fuzzers and more bug detectors.

Please let me know if you have any questions regarding fuzzing or the OSS-Fuzz integration.

appenderList is now never null:

https://github.com/qos-ch/reload4j/commit/63ff036d11b14767365197a79606cb6df6102c3a#diff-e36ce72be14b72b7656aa689c45e327e1c84bedccd4191fc54e959322b494519R35

Which means that code that used getAllAppenders() == null to decide if appenders were not configured now doesn't work ( we have programmatic configuration of loggers happening). It should be initialized here to keep the existing nullability behaviour:

https://github.com/qos-ch/reload4j/commit/63ff036d11b14767365197a79606cb6df6102c3a#diff-e36ce72be14b72b7656aa689c45e327e1c84bedccd4191fc54e959322b494519L48

Hi,

We just got a bottleneck in production with 2000+ threads blocked waiting on the lock in the synchronized block of callAppenders() in Category.

This never happend before to us, including in stress tests.

However, I seem to think a small performance improvement could be made with a simple open call (if I'm reading the code correctly).

    public void callAppenders(LoggingEvent event) {
	int writes = 0;

	for (Category c = this; c != null; c = c.parent) {
	    // Protected against simultaneous call to addAppender, removeAppender,...
        // open call, read the values under lock:
        AppenderAttachableImpl aai;
        boolean additive;
	    synchronized (c) {
            aai = c.aai;
            additive = c.additive;
        }
        // open call
        if (aai != null) {
            writes += aai.appendLoopOnAppenders(event);
        }
        if (!additive) {
            break;
        }
    }

Since aai is final and is a thread-safe data structure, we only want correct visibility of the aai and additive fields and we don't need to block the whole category object while calling appendLoopOnAppenders.

What do you think?

Best regards, Dominique

Hi,

Currently I have updated my project from log4j 1.7 to reload4j1.9 everything works fine but one functionality breaks Exception in thread "AWT-EventQueue-2" java.lang.NoClassDefFoundError: org/apache/log4j/lf5/viewer/categoryexplorer/TreeModelAdapter

I have checked and found that reload doesn't contain this package Any help will be appreciated