[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

[DennisAtDept]

Hi @gmazza,

Thanks for the reply I guess we will start using your form as well, build the project and include the artifact in our nexus.
Perhaps for others, might be cool to have your artifact available for the general public.

[roechi]

I believe this has been fixed with v1.6.0.