Inspiring

Answered

zero-day exploit affecting the popular Apache Log4j utility (CVE-2021-44228)

Forum|Forum|4 years ago
December 10, 2021
30 replies
65943 views

Does anyone know if the zero-day exploit affecting the popular Apache Log4j utility (CVE-2021-44228) that was announced on 12/9/2021 will affect ColdFusion version 10 and 2018?

This topic has been closed for replies.

Correct answer Priyank Shrivastava.

Hi Everyone,

We had originally published (on Dec 14) some workaround/mitigation steps in this article until the patch would be released. Since then, there have been updates and still further updates.

Dec 14: Technote with initial mitigations offered:

https://helpx.adobe.com/coldfusion/kb/log4j-vulnerability-coldfusion.html

Update Dec 17: Updates for CF2021 and 2018 were released, addressing this log4j vulnerability. The technote mentioned above was a preliminary response, offered on Dec 14.

Update Dec 21: To address the vulnerabilities later found in log4j 2.16, those who have applied the most recent update can now implement the log4j 2.17 updates, as provided along with instructions here:

https://helpx.adobe.com/coldfusion/kb/log4j-2-16-vulnerability-coldfusion.html

Update Jan 11 2022: To address the vulnerabilities later found in log4j 2.17, those who have applied the most recent update can now implement the log4j 2.17.1 updates, as provided along with instructions here:

https://helpx.adobe.com/coldfusion/kb/log4j-2-17-0-vulnerability-coldfusion.html

Miguel-F

Inspiring

In case you missed it, Adobe has released a statement on this issue today January 11, 2022.

Log4j 2.17.0 vulnerability on ColdFusion

AnthonyKolka

Participant

How much would you like to bet that someone will prove them wrong? If they haven't already.

N

NicoTexas6144274

Participating Frequently

And now there is a new version of Log4J 2.17.1 https://logging.apache.org/log4j/2.x/security.html to deal with https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44832 which is a moderate severity.
But as mentioned before Log4J is under scrutinity and our infosec team is asking relative quick response even for such moderate risk.

Also, how does you get all the hot fixes patches for 2018 update 13?

BKBK

Community Expert

And now there is a new version of Log4J 2.17.1 https://logging.apache.org/log4j/2.x/security.html to deal with https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44832 which is a moderate severity.

By @NicoTexas6144274

I have created a bug ticket on this at Tracker. ( https://tracker.adobe.com/#/view/CF-4212652 ) Unfortuinately, in recent days, Tracker fails to show any ColdFusion bug ticket created.

Also, how does you get all the hot fixes patches for 2018 update 13?

I would proceed as follows (in my test environment first, before moving on to production):

To prepare to install Update 13, make a backup copy of any hotfix JARs present in Update 12. If you have any, they will be in /lib/updates/. For example:

/lib/updates/hf201800-4208163.jar
/lib/updates/hf201800-4212383.jar

2. Install Update 13: https://helpx.adobe.com/coldfusion/kb/coldfusion-2018-update-13.html

3. Replace the following log4j JARs, where x is between 10.0 and 17.0)

/lib/log4j-api-2.x.jar
/lib/log4j-core-2.x.jar
/lib/log4j-to-slf4j-2.x.jar

respectively with

/lib/log4j-api-2.17.1.jar
/lib/log4j-core-2.17.1.jar
/lib/log4j-to-slf4j-2.17.1.jar

4. Copy any hotfix JARs you backed up back to /lib/updates/
5. Restart ColdFusion.

Charlie Arehart

Community Expert

Following up on BKBK's suggestion of how to proceed with updates, as well a tracker ticket he offered (on log4j 2.17.1), I have a couple of thoughts that I hope may help some readers, based on how I (as well as he) have been helping folks with these updates for a couple of weeks.

1) Curiously, BKBK, that tracker ticket is not there. Did you get notification from them as to why? I see someone else created one the next day, https://tracker.adobe.com/#/view/CF-4212654, so folks could at least watch that (and vote for that, as I just did).

2) Also, as for his instructions to backup and restore "of any hotfix JARs present in Update 12"), I do fear some readers might easily missing some subtle points.

a) First, when he refers to "any hotfix jars present" in that lib/updates folder, please note he means any jars whose names start with "hf". Those are special hotfix jars that Adobe sometimes offers to fix bugs in some given CF update. (I have a blog post with more on those, if interested.) My point here, though, is that you will ALSO see there a file starting with a whose names "chf", and that is THE hotfix file for that update you're currently on. You do NOT want to "restore" that older CHF jar into your new update, only any HF jars.

b) Further, you really do want to do this only if you are the previous CF update, update 12 in the case of CF2018. If you are on any PRIOR update of CF2018 before doing this latest update, and you find any hotfix jars there, you do NOT want to restore those. They are fixes to previous updates, which were resolved in later updates. More on that in a moment.

c) Third and finally, he is referring to "update 12" (of CF2018) here simply because he was responding to a question regarding CF2018,. But all this applies as well to CF2021. Those who may be on update 2, who find any hf*.jar files in the lib/updates, would want to restore those after doing update 3. (But if you are on update 1 or have no updates, then don't restore any hf*.jar files.)

3) For those whose heads may be spinning and who could use some additional context: the problem all this is referring to is that update 12 of CF2018 (as well as update 2 of CF2021) had some bugs, and Adobe offered some hotfix jar (hf*.jar) files to address those, which some people had added to their update 12 (or update 2 of CF2021) implementations. When you move to update 13 (or update 3 of CF2021)--or indeed when you move to any new CF update, the update mechanism intentionally removes any such hf.* jar files that had been in the lib/updates. The update mechanism presumes that the new update incorporates any and all fixes to the prior updates.

But in the case of this latest emergency CF update released Dec 17, Adobe ONLY took the previous version (update 12 for CF2018, or update 2 of CF2021) and they modified it to update the log4j 2 files (to 2.16) and also to update some log4j1 jars. But they specifically did NOT incorporate ANY bug fixes to updates 12 or 2.

And this is why people who move from THOSE updates--who had applied hotfix jars to THOSE updates--need to re-implement those hotfix jars.

On the other hand, if you are MOVING to these latest versions of CF2018 or 2021 from some EARLIER version, now YOU are faced with the prospect of being hit by the bugs that were introduced in updates 12 and 2, respectively, and which remain in updates 13 and 3.

4) Yes, all this is messy. Yes, some will complain that they SHOULD have rolled in any and all current bug fixes. But that would take time to do, test, do integration testing, etc. and as this was an emergency update they opted for just modifying things based on the previous update.

Others (especially those on update 12 or 2, with such hotfixes) might have complained if they HAD done anything more than "just address the log4j issue".

And of course, still others will wish they had somehow provided for ONLY dealing with that for WHATEVER current update (of CF2018 or 2021) that someone was on. Then folks who had NOT yet moved to update 12 or update 2 would not now be encountering issues. (And sadly, no, there is no current listing from Adobe of what hotfixes DO exist for updates 12/2 that should be considered for those moving to updates 13/3.)

This is the current state of things, and we now wait for Adobe to clarify proceeding with updating to the 2.17.1 (or later) jars.

We can certainly expect that some later update 14 or 4 WILL incorporate the needed bug fixes...unless some new emergency interrupts those plans.

(And of course, none of this discussion of 2.x log4j jars applies to CF2016 or earlier, as they don't include that by default. And Adobe has offered no guidance on updating the log4j 1.x jars they may contain.)

PS Actually, there is still one remaining issue. As I brought up back on Dec 27 here (as have others), even CF2021 and 2018 include log4j 1.x jars in the cfusion/jetty folder (if one added the CF "add on service") that were NOT modified by the update to CF. Adobe has yet to respond to or address that, that I have seen.

/Charlie (troubleshooter, carehart. org)

N

neowire

Inspiring

Regarding ColdFusion 2016...

Is there anything that can be done to update from Log4j v.1.x to v.2.1.7 or newer.

As of CVE-2021-4104, we are being forced to upgrade Log4j. (Upgrade to Apache Log4j version 2.16.0 or later since 1.x is end of life.)

Would really appreciate anyone's feedback regarding this? I understand that core support for ColdFusion 2016 has expired, but is there anything that can be done to manually update these files?

Charlie Arehart

Community Expert

Adobe folks, why has nothing been done about updating the class files within the log4j-1.2.17.jar, found within cfusion\jetty\lib\ext\ in both CF2021 and 2018, even after the Dec 17 updates?

To be clear, I do understand that the log4j-1.2.15.jar in the cfusion/lib of CF2018 (after update 13) HAS in fact been modified to remove the vulnerable classes, like jmsappender.class. But I am NOT seeing that those vulnerable classes have been removed from the log4j-1.2.17.jar in the cfusion/jetty/lib/ext.

That seems an oversight. Might you perhaps create another technote that points this out and offers folks an updated version of the jar file that DOES remove those vulnerable classes?

I realize also that some people are raising the concern that their security scanning tools are triggering on the mere PRESENCE of files with names like that log4j-1.2.15.jar in CF2018's cfusion/lib, even when that HAS been updated to remove the vulnerable classes. At some point, it seems you really will have to just update CF to REMOVE those log4j 1.x jars, whatever it takes. Otherwise, too many folks will be unable to fend off their less-sophisticated security folks, who don't generally want to stop at hearing or even seeing prood that "the vulnerable classes were removed from the jars".

But again, that's separate from the current problem that the jetty/lib/ext folder has a truly vulnerable log4j 1.x jar, even after the Dec 17 updates.

(If somehow I am misunderstanding or misrepresenting things, I do apologize. I really don't want to raise the panic level any further, esp as we enter the holiday season.)

/Charlie (troubleshooter, carehart. org)

ccsimmons_FAVER

Inspiring

I meant to reply to this post with the following:

Are you aware of step by step published anywhere to mitigate the presence of C:\ColdFusion2021\cfusion\jetty\lib\ext\log4j-1.2.17.jar? The install we have is with a government agency and this file is causing a Nessus security scan failure. If we don't find a way to pass that scan they will pull the plug on the server.

Ripley Casdorph

Participating Frequently

The Jetty folder is used for one of the monitoring services that we don't use and I was able to replace with a 2.17 version, no issues for us. We were getting killed on that too!

W

w49369461

Participating Frequently

@Priyank Shrivastava. What is happening with extra DoS vulnerability in log4j 2.16? THis has now been updated to 2.17.

Will Adobe be updating the hotfix? Should we manually update?

A

aarnir71156744

Participating Frequently

Hmm,

A quick manual try on a local vbox to 2.17 gives a bunch errors after cf restart.

Going back to 2.16 after that, same. Err...

BKBK

Community Expert

A quick manual try on a local vbox to 2.17 gives a bunch errors after cf restart.

By @aarnir71156744

Could you please share the error messages you got.

R

rgjason2

Participating Frequently

It appears something else changed besides log4j in the hotfix v3 for 2021

QoQ started returning: java.lang.UnsupportedOperationException: getColumnType() at coldfusion.sql.QueryTableMetaData.getColumnType(QueryTableMetaData.java:783) at coldfusion.sql.QueryTableMetaData.getColumnType(QueryTableMetaData.java:773)

Query is basic:

<cfquery name="retVal.currSum" dbtype="query">
SELECT rs_name,
SUM(last_count) AS last_count,
SUM(proj_amount) AS PROJ_AMOUNT
FROM retVal.Curr
GROUP BY rs_name
</cfquery>

Adding cast() didn't help either

<cfquery name="retVal.currSum" dbtype="query">
   SELECT rs_name,
   SUM(CAST(last_count AS INTEGER)) AS last_count,
   SUM(CAST(proj_amount AS DOUBLE)) AS PROJ_AMOUNT
   FROM retVal.Curr
   GROUP BY rs_name
</cfquery>

R

rgjason2

Participating Frequently

looks like Update 3 removed hotfixes that might have been applied such as hf202100-4212383.jar. Re-installing fixed.

Whatfore

Participating Frequently

I'm still using CF10, which based on this thread seems like it's probably not affected by this exploit. But, if I do add the "-Dlog4j2.formatMsgNoLookups=true" to my java args, will it be a problem?

BKBK

Community Expert

I'm still using CF10, which based on this thread seems like it's probably not affected by this exploit. But, if I do add the "-Dlog4j2.formatMsgNoLookups=true" to my java args, will it be a problem?

By @Whatfore

I think it won't be a problem. However, I would suggest that you don't add it.

It is bad practice to initialize variables that are never used anywhere in your application. The same applies here. After all, -Dlog4j2.formatMsgNoLookups=true is just Java initialization code.

P

paule12345

Inspiring

FYI in regards to version 2.15, I just received this notice from our datacenter provider:

"... an additional vulnerability has been identified in the previously released fix for CVE-2021-44228. This new vulnerability impacts Apache Log4j 2.15.0 and has been identified as CVE-2021-45046. If exploited, this vulnerability could result in a denial of service (DOS) attack. This vulnerability has been addressed in Log4j version 2.16.0."

BKBK

Community Expert

FYI in regards to version 2.15, I just received this notice from our datacenter provider:

"... an additional vulnerability has been identified in the previously released fix for CVE-2021-44228. This new vulnerability impacts Apache Log4j 2.15.0 and has been identified as CVE-2021-45046. If exploited, this vulnerability could result in a denial of service (DOS) attack. This vulnerability has been addressed in Log4j version 2.16.0."

By @paule12345

Which doesn't surprise me. I think it's best to implement solutions as soon as they come along. So, you should move from 2.15 to 2.16 right away. After all, you have 0 days to act. 🙂

N

neochad

Inspiring

Can someone at Adobe please reach out and tell us what the 2.x versions of log4j are used for? I have contacted every support group I can and am getting nothing we are week out and I feel like adobe has just abandoned this thread since they put out the remediation steps.

Most of the jar files I can find in the ColdFusion application files are referencing log4j 1.x. Some information about how ColdFusion might be affected would be seriously benefecial to admins. I even think the verbiage changed on the https://helpx.adobe.com/coldfusion/kb/log4j-vulnerability-coldfusion.html page and no longer includes the "Adobe has discovered no indication to suggest custom data has been impacted as a result of this issue".

Which if it has, is very concerning, and we need to get clear information as to the extent that we were vulnerable.

S

Segfault

Participating Frequently

Yes this.
We need to know if there was a window of reasonable vulnerability at any point.
This is essential also from a compliancy angle!

It's been a week and I still can't tell anyone more then that we've remediated the issue in our expensively licensed webserver.
There's no patch. And there's no info to the extend coldfusion was vulnerable to begin with.

Guys over at LUCEE had this cleared up the day it was discovered, just saying.

@neochad I don't think the sentence about adobe not having found a exploitable problem was ever actually on that support page. It's a service desk reply someone got that should be somewhere in the comments here.
Not that that's in any way relevant to the point at hand, but just saying.

N

neochad

Inspiring

You could very well be right, I may have transposed that in the flurry of responses that have been floating around.

P

Pete220652393l9r

Known Participant

Hello,

We applied the mitigation until the patch is released. In doing so, it broke our SSO integration.

what we did:

-Dlog4j2.formatMsgNoLookups=true to Jvm.config

the error we get when the saml request is initialized

"The system has attempted to use a undefined value, which usually indicates a programming error...."

removing the mitigation makes it work -

T

T.Brown.10

Participating Frequently

Just a follow up question on this. When the sso broke it wasn't around the time that the AWS outage was occuring. Because ours broke with strange error messages around then and the underlying cause was our MFA provider went down with the outage

Show more replies

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded