[CVE-2021-44228] zero-day in the Log4j Java library

[kyleabcha]

Hi,

There's a serious vulnerability in the Log4j Java.

https://www.lunasec.io/docs/blog/log4j-zero-day/

We are using FuelSDK-Java, does FualSDK-Java suffer from CVE-2021-44228?

[roechi]

Looks like it! Fuel SDK currently uses log4j version 1.2.17.

[kyleabcha]

Hi,
we will need a new version of FuelSDK-Java which supports the latest Apache Log4j.
Can salesforce-marketing-cloud update the FuelSDK-Java?

[roechi]

I did a bit more research. Apparently the mentioned vulnerability exists only for log4j versions between 2.0-beta9 and 2.16.0. However, version 1, as it is included here, is susceptible to other Remote Code Execution attacks! (source: https://www.lunasec.io/docs/blog/log4j-zero-day/#affected-apache-log4j-versions)

[roechi]

This PR upgrades log4j to the latest and safe version 2.16.0 and adjusts logger usage according to the newer API. I was not able to run all tests since they seem to have additional requirements towards the build/test environment.

[roechi]

I updated the PR to use the Log4j 1.2 API instead. This way, all we have to do is exchange the log4j dependency. All logger interactions stay the same. Thanks to @idealec for pointing this out to me!

[kyleabcha]

thanks @roechi for your review. I replaced log4j-1.2.17.jar with log4j-api-2.16.0.jar and log4j-1.2-api-2.16.0.jar in the classpath. It seemed that the new log4j 2.16.0 does not support Java 6. It causes the regression test to fail. Could you review it?

java.lang.UnsupportedClassVersionError: org/apache/log4j/Logger : Unsupported major.minor version 52.0
	at java.lang.ClassLoader.defineClass1(Native Method)
	at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
	at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
	at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:141)
	at java.net.URLClassLoader.defineClass(URLClassLoader.java:283)
	at java.net.URLClassLoader.access$000(URLClassLoader.java:58)
	at java.net.URLClassLoader$1.run(URLClassLoader.java:197)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
	at com.exacttarget.fuelsdk.ETConfiguration.<clinit>(ETConfiguration.java:47)

[roechi]

@kyleabcha the overview page of the Log4j 2 project states: As of Log4j 2.13.0 Log4j 2 requires Java 8 or greater at runtime. (see: https://logging.apache.org/log4j/2.x/)
It does not seem like there is a legacy branch to keep up compatibility with older Java versions.

[kyleabcha]

FuelSDK-Java does support Java 6 compiler as it defined in pom file

<maven.compiler.source>1.6</maven.compiler.source>
<maven.compiler.target>1.6</maven.compiler.target>

Can FuelSDK-Java provide a workaround or a new patch that fixes Log4j 2 issue?

[gmazza]

I've forked the main branch and upgraded code to latest Apache Log4J and CXF as explained here:
#134 (comment)

Code is quite new however (just several hours old) and probably will have more than its share of problems.

[DennisAtDept]

Hi all,

Thank you for your time and efforts.
@gmazza will your changes by any changes be merged with the main branch? We are also looking into having the FUELSDK updated in our project.

[gmazza]

@DennisAtDept I don't see SF acting on it. However, happy to note my branch seems to be working fine in production at work for the past few days.

[DennisAtDept]

Hi @gmazza,

Thank you for all of your efforts, we tried out V1.6.0 of the FuelSDK-java but are encountering NoClassDeffFoundErrors when trying to use it.

[INFO] [talledLocalContainer] java.lang.NoClassDefFoundError: org/apache/log4j/Logger
[INFO] [talledLocalContainer] at com.exacttarget.fuelsdk.ETApiObject.(ETApiObject.java:61) ~[fuelsdk-1.6.0.jar:?]

Is seems like the FuelSDK still (at least partially) expect log4j1 to be present. Or are we missing something?

[gmazza]

Hi @DennisAtDept, the SF fork is different from mine, they're using separate code, if there are problems with it you may wish to open a new issue over it. But, for what it's worth, my fork seems to be working fine at work past couple of weeks now, and so I have no desire to go back to the main SF one: https://glenmazza.net/blog/entry/fork-of-fuelsdk-java-created