Security scans flagging older versions of log4j

[Matthew22377144yk0g]

Our IT department runs security scans using tenable and they are flagging older versions of log4j on our coldfusion servers.  We are running CF2018 patch 13, and have removed all our old hotfix history - the only older versions of log4j on our server now are log4j-1.2.15 in Coldfusion2018\cfusion\lib and log4j-1.2.17 in Coldfusion2018\cfusion\jetty\lib\ext.  Can we confirm whether or not these versions of log4j are vulnerable, and, if so, if there's any mitigation strategies that we can use to make sure these two log4j versions are secure?  Is there any plan to replace these with log4j 2.17?

[BKBK]

From what I have read from the documentation so far,  log4j-1.2.x is not vulnerable.

[Charlie Arehart · Accepted solution]

BKBK, while it's true that the broad concensus in the early days of the news about log4jshell (starting Dec 9)  was indeed that "it affected only log4j 2.0-2.15, then 2.16, and finally fixed as of 2.17 as of now), subsequent CVEs identified a rather edge case scenario in even log4j 1.x files.

As such, folks are indeed finding that scanners (which look by file name) are tripping over the fact that CF2018 has this log4j-1.2.15.jar file in its cfusion/lib folder (or if running multiple instances, the [instancename]/lib folder).

About that, Matthew, note first that Adobe DID updat that jar, with update 13. If you were to compare the jars before and after (jars are just zips) you would see that they removed the vulnerable jmsappender.class and some others, as has bene recommended by the log4j project and community abotu the log4j 1.x vulnerability.

The problem is that too many scanners are looking ONLY at the NAME of the jar, not what is IN the jar. That's borderline criminal, really, because any bad guy (or software) could name the jars anything they want. A better scanner WOULD go that extra step and look IN any jar files to see IF they have known vulnerable class file names (that's still a "filename check", but at least it's not just a surface one).

Anyway, folks like Matthew are in a pickle because "they have what they have" and need to "do what they tools says to do". But to be clear, Matthew, no, that jar is NOT something you can replace. In fact, the update 13 DID implenent a log4j 2.16 jar, and then the technote from Adobe earlier this week now allows you to copy in log4j 2.17 jars (over the 3 log4j 2.16 jars)--and the technote even offers a zip with the files.

But after doing that, one STILL will have the log4j-1.2.15.jar. And you can't "just delete that" jar. If you do, CF will start but CF pages (and the CF admin) won't run. They rely on something in that jar (even though it CAN'T be any of the vulnerable bits as Adobe has removed those as of update 13). As I shared  just now in the much larger forum thread here on log4j, one COULD rename that file. Java (and therefore CF) really don't care about the name of the file. But I realize that's not a satisfying solution.

But Matthew, I have offered for now what I understand to be the situation about that log4j-1.2.15.jar.

Now, about the log4j-1.2.17.jar, which is in that jetty lib that Matthew mentions (in both CF2018 and 2021 even after the updates of Dec 17), that is dismaying to notice. I see now that it was raised back on Dec 13 by FishDev, but it was NOT addressed in the update on Dec 17, nor have I seen it discussed in the technotes they've released before or since. (Well, one of them talks about removing vulnerable libraries from "3rd party applications", but technically the jetty embedded within CF is not a "3rd party" app.)

Anyway, I just want ahead and raised the question/concern, directing it to Adobe, as a new reply in that longer thread. Matthew, you may want to follow that aspect of the discussion there.

Until then, again you COULD do that removal of the vulnerable classes  (by extracting the jar as a zip, removing the classes, and re-compressing the jar, as discussed in the technote). But really, Adobe should be fixing this for us, perhaps as a new technote with a new jar offered with those removed for us. That's what I've requested in that other thread.

[BKBK]

@Matthew22377144yk0g, rest assured that if, in the present atmosphere there is a vulnerability that affects log4j-1.2.x, Adobe will be aware of it and will fix it promptly. So, relax.

[Matthew22377144yk0g]

Thanks Charlie - this is really useful information, and thanks for bringing this issue into the other thread.  I agree - Adobe should be taking care of the 1.2.17 jar for us, but it does give me an alternative in case our security team forces the issue.

[altascene]

Charlie,

I have a similar situation, in that we are also using Tenable for vulnerabiltiy scanning.  Our scenario is that scans are detecting that log4j-core-2.9.0.jar is present in a backup location;

Path : C:\ColdFusion2018\cfusion\hf-updates\hf-2018-00011-326016\backup\lib\log4j-core-2.9.0.jar

Tenable basically says "...if it's present, it's a vulnerability...".  My options are to accept the risk within their system, or delete the file.  If I never plan on "rolling back" to update 11, may I safely delete the old log4j file?

Thanks,
Scott

[BKBK]

If I never plan on "rolling back" to update 11, may I safely delete the old log4j file?

Scott

By @altascene

Yes.

In which case, I would delete the entire update.

[altascene]

BKBK,

Thanks for the information.  So, to clarify, do you mean that I may delete the entire folder (\hf-2018-00011-326016) from the hf-updates folder?

Thanks,

Scott

[BKBK]

Yes. But you should try to run the uninstaller first. 

I would proceed as follows ( there is a caveat * )

1.  Open the Command Prompt as Administrator.
2.  Use CD to navigate to the /bin directory of the Java installation on which ColdFusion is running.
        For example, in my case, it is: C:\Program Files\Java\jdk-11.0.13\bin
3.  Run update 11's uninstaller.jar. The DOS command is something like
        java -jar C:\ColdFusion2018\cfusion\hf-updates\hf-2018-00011-326016\uninstall\uninstaller.jar
4.  That should uninstall update 11. If it does, okay. If it doesn't, then I will go out on a limb here and say that we could still go ahead with the following step.
5.   Stop all ColdFusion instances.
6.   Delete the directory \hf-updates\hf-2018-00011-326016, the file \hf-updates\hf-2018-00011-326016.properties and the file \hf-updates\xxx-xxx-326016.jar
7.  Restart the ColdFusion instances.

* In matters like these, the ColdFusion Team knows best. So confirm these steps with them beforehand (cfinstal|at|adobe.com).

[altascene]

BKBK,

Thanks.  On a dev box, I removed all the hf-2018-xxxxx-xxxxxx folders from the \hf-updates folder.  I left the .jar files and .properties file in-place.  I then re-ran the vulnerability scan, and it "passed".  When I say "removed", I first tried moving the folders to a different location on the server.  The scanner still found them, so I removed them completely.

I did not perform uninstalls first, nor did I stop the CF App Server before I moved the files off of the server.  The sites being served from the dev box are working, and I am not seeing any odd error messages from CF.

Yes, please, CF Team, feel free to chime in on whether or not the above steps I performed is advisable.

[BKBK]

On a dev box, I removed all the hf-2018-xxxxx-xxxxxx folders from the \hf-updates folder.

By @altascene

No better place to test.

I left the .jar files and .properties file in-place. 

No need, in my opinion. After all, you've gutted the vital organs.

[altascene]

BKBK,

Yes, I have come to realize that my rather over-zealous method removed all of the updates to CF.

I put everything back, and things are working as desired.  I also now realize that the scanning software is telling me exactly what to relocate.  I have renamed the specific file it found in the update\backup folder.

[Charlie Arehart]

BKBK, am I reading you right here? Are you suggesting that to solve the problem of the old jar being in the backup for update 11, Scott should have tried to run the uninstall of update 11. That would not be correct.

I'm referring to your step 4 in the comment I'm replying to, where you said "That should uninstall update 11. If it does, okay."

To be clear, running a CF update uninstaller does not just "remove that update from the hf-updates folder" (as it seems you may be suggesting). Instead, running an uninstall of a CF update would roll back the CF instance itself to whatever update had been installed BEFORE having done that update you are uninstalling.

Scott indicated that update 11 was in his hf-updates folder (and was wanting to deal with the log4j 1.x jar in its backup folder) so clearly he had installed either update 12 or 13.  So no, he (or someone in this situation) would NOT want to run the uninstaller to "get rid of the the old jar". (Indeed, as I noted in my first comment above, the log4j1.x jar implemented by update 13 is in fact an UPDATED one that REMOVES the vulnerable classes, so running the uninstaller would BRING BACK the version of that jar that was NOT updated.)

Thankfully, CF detects an attempt to do this (trying to uninstall an update which is older than the one you are currently on) and it blocks the attempt (a couple of screens into the installer UI, or a couple of prompts with the headless uninstaller). I confirmed this just now, in CF2021, 2018, and 2016.

So anyway, no offense intended. I just felt this needed to be clarified, lest someone see that comment and misconstrue it. Sorry if somehow I did, too.

And I see the other discussions you guys had where it seems you did finally resolve things, Scott. That's what matters most.

[BKBK]

BKBK, am I reading you right here? Are you suggesting that to solve the problem of the old jar being in the backup for update 11, Scott should have tried to run the uninstall of update 11. That would not be correct.

By @Charlie Arehart

No, nowhere do I suggest that. In fact, what I suggest has nothing to do with, as you put it, the problem of the old jar.  Those are your words.

Take a look back. My suggestion has to do with the removal of the archived files of a previous installation. 

To be clear, running a CF update uninstaller does not just "remove that update from the hf-updates folder" (as it seems you may be suggesting). 

No, I certainly do not suggest that. Again these quotes are your words, not mine. Why do you keep making statements, putting them in my mouth, then building up arguments against them? 

What I suggest is to run an update's uninstaller to uninstall the update. Just in case there is some residual throwback. If on running the uninstaller nothing happens, then we will know. We will then be more confident in deleting the uninstaller archive.

Instead, running an uninstall of a CF update would roll back the CF instance itself to whatever update had been installed BEFORE having done that update you are uninstalling.

The updates in question are cumulative. Hence the tacit assumption is that this pertains to the earliest update - update 11 in the example - and that there is no update before. 

Scott indicated that update 11 was in his hf-updates folder (and was wanting to deal with the log4j 1.x jar in its backup folder) so clearly he had installed either update 12 or 13.  So no, he (or someone in this situation) would NOT want to run the uninstaller to "get rid of the the old jar". 

No one wants to do that, as far as I know. The quotes are again your own words. 

So anyway, no offense intended. I just felt this needed to be clarified, lest someone see that comment and misconstrue it. Sorry if somehow I did, too.

 No offense taken, Charlie. I only hope that, upon a clarification like this, there will still be people in the room.

[Charlie Arehart]

I hear you, but again someone in Scott's position (on u13) could not run the uninstall of u11. That will be blocked. More important, they should not, if their focus (like Scott's) was to get rid of the old log4j 1.x jar being found by their security scanner. We can leave this be, with others assessing our last 3 comments in their context. 

[altascene]

Matthew,

I don't know what you are finding, but I have found that Tenable is detecting all update backup files, regardless of their location.  I don't know whether this causes issues with the CF installation.

Scott

[altascene]

After I read my comment above, I felt the need to clarify.  I meant that, regarding Log4j, for Tenable to give a CF server a clean bill of health, you must remove all of the backup files from that server.  I confirmed that, but I do not know if there is a negative impact by removing all of the backup files.

[BKBK]

... I do not know if there is a negative impact by removing all of the backup files.

By @altascene

The backups are basically there to enable you to re-install or to revert to a previous installation if and when necessary. If you remove update X's backup, the impact will be that you will no longer be able to re-install or to revert to update X.

There are 3 data per update, comprising the update directory, the jar, and the properties file.

For example, for CF2018 Update 12, they are:

\hf-updates\hf-2018-00012-328566\,

\hf-updates\hotfix-012-328566.jar,

\hf-updates\hf-2018-00012-328566.properties.

If you delete these, you will no longer be able to re-install or to revert to update 12.

[altascene]

I thought of that.  Right now, I am just renaming the log4j-core file that the scan finds, from log4j-xxx-xxx.jar, to log4j-xxx-xxx.savjar.  Yes, if I ever wanted to roll back, I would need to undo that first.  However, I do not currently see a scenario where I will need to roll back.  I do not see how the above would cause issues with future CF Updates.  However, if it did, I would just rename the file in the U13 \backup folder, and try it again.

[Matthew22377144yk0g]

We actually just zipped up all our old hotfix backups and moved them to a different location on the same server - that was enough to get past the scan.