Are there Log4j vulnerabilities in ColdFusion2021, Update 18?

[Dordrecht]

Hi, all. 

I recently asked about Log4j vulnerabilities in CF2023, and learned that there are not any known at this time. Now, I need to ask whether CF2021, Update 18 has any Log4j vulnerabilities.

The main reason I ask is because I have CF2021 Update 13 installed locally, and when I match the files that @Charlie Arehart mentioned in one of his linked articles, I find that of the files he indicates should exist in (CF_Home)/lib folder prior to file replacement with 2.17.1 versions:

• log4j-core-2.16.0.jar
• log4j-api-2.16.0.jar
• log4j-to-slf4j-2.16.0.jar

My directory has only these unversioned files (with no corresponding file for log4j-to-slf4j)

• log4j-core.jar
• log4j-api.jar

Possibly the files I have are version 2.16.0, although not named as such? I'm not sure how to check the versions programmatically, and I don't see that the installed Log4j versions are listed anywhere in the CF Admin.

In a nutshell, will updating to CF2021 Update 18 remove all known Log4j vulnerabilities, or would further fixes still be necessary?

Thank you!

[Charlie Arehart · Accepted solution]

@Dordrecht , those files without a number (as you find after recent CF2021 updates) are in fact the right ones. This started with CF2021 update 11 (in Oct 2023), which implemented log4j 2.20.0. Before that it was 2.17.0 (and the blog posts you point to are from even before that, when previous CF updates had implemented the 2.16 version).

How can you confirm this from the files themselves? You ask "how to check the versions". Here's how:

• You can explore the jar files by treating them as zip files.
• You use a tool like 7zip whose UI has an "open archive" feature that lets you explore the files, or you can use any zip tool to tell it to extract the jar as a zip, or you can simply copy the file to the name name with a .zip extension and then view it in even Windows Explorer
• Inside the jar/zip, you'll find such files as META-INF\MANIFEST.MF which has lines such as Implementation-Version: 2.20.0, showing that it's version 2.20 of the log4j files, rather than that 2.16 version indicated in the file name in the past.
  • (And if anyone doubts the MANIFEST.MF file info--because there's a lot there--you cna look instead at META-INF\maven\org.apache.logging.log4j\log4j-core\pom.properties which has just 3 lines, starting with artifactId=log4j-core and ending with version=2.20.0.)

As for the fact that the log4j.jar has no version number in the name, I'm inclined to think that's a choice of the log4j team rather than the cf team.

Let us know if that resolves things for you, and if so, please mark this reply as the "answer" to the thread, to help future readers looking at it.

[Dordrecht]

Thank you, @Charlie Arehart! I followed the steps you mentioned to check the version and it is indeed 2.20.0.

[Charlie Arehart]

Very good to hear, and thanks for marking the answer, for the sake of future readers. 🙂 

[BKBK]

Are there Log4j vulnerabilities in ColdFusion 2021, Update 18?

By Dordrecht

No.

The ColdFusion team did remove the vulnerable 2.x versions of log4j - that is, versions 2.17 and below - from early updates of ColdFusion 2021. So, recent ColdFusion 2021 updates, such as 15, 16, 17 and 18, don't have the vulnerability. To be sure, find out your log4j version using the following code 

<cfset obj=createobject("java","org.apache.log4j.Layout")>
Log4j implementation version: <cfoutput>#obj.getClass().getPackage().getImplementationVersion()#</cfoutput>

In a nutshell, will updating to CF2021 Update 18 remove all known Log4j vulnerabilities, or would further fixes still be necessary?

By Dordrecht

Yes to the first question and, perhaps to the second..

As explained above, to avoid the log4j 2.x vulnerabilities, the ColdFusion team has upgraded the log4j 2.x used by recent ColdFusion 2021 updates. Nevertheless, so you can never be 100% sure.

Software vulnerability is a risk, so there is always that 0.001% uncertainty. All you can do is protect as strongly as you can.  For example, the protection might be even stronger if, in addition, your jvm.config contains the formatMsgNoLookups  flag

-Dlog4j2.formatMsgNoLookups=true