[Posted: Dec 13, 2021. Updated: Dec 14, 2021, as indicated below]

TLDR: I provide here resources with suggestions of what to do about the log4jshell vulnerability, while we await an update from Adobe. And I share the current JVM arg being proposed as “the solution” to mitigate the vuln (-Dlog4j2.formatMsgNoLookups=true). Finally, I offer a bit of opinion on how things have gone so far.

Updated since original post: Within hours of my posting this, Adobe released an information page with more on the currently available responses (as yet, still no update).

Background

It’s very likely you have been hearing for days about the vulnerability in the log4j Java library, which has been discussed widely in IT circles since late Thursday Nov 10. The general theme is that since log4j underlies nearly all Java applications, this is tantamount to a worldwide IT pandemic.

And you have also likely heard that since CF runs on Java, and includes log4j, we who use ColdFusion must be concerned and your stakeholders may be demanding that you “take action”. Most important, you may lament that you’ve heard very little (to now) from Adobe on their response to this situation. Is there an update to be made available for CF2021 or 2018? And what about those not on those supported CF versions?

For now, there’s no new update from Adobe. (That could change within hours of my posting this.)  Update: again, within hours of my posting this, they created an “official” page with information, but as yet no update.

When there is a new CF update, we should expect to be an update only for CF2021 and 2018, the only two supported versions of CF. You can see if/when Adobe updates those on the CF updates page for CF2021 and for CF2018.

Folks on all CF versions should read on.

Where can you learn more, until Adobe offers an update?

Until Adobe offers an update (or for those on older CF versions), I would recommend anyone interested in this matter to look into the discussion happening in the thread at the Adobe CF community forum:

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

It’s been updated daily since the news started Friday and includes many suggestions and ideas to chew on.

As for a single blog post that also is trying to pull together “what can you do” (especially until Adobe may offer a fix), see Pete Freitag’s blog post from Friday (also updated daily since):

Log4j CVE-2021-44228 Log4Shell Vulnerability on ColdFusion / Lucee

I’m sure both resources will be updated when Adobe releases an update. I’ll try to do the same in this post, or will at least offer a comment below.

What can you consider doing before Adobe offers an update?

First, in both resources above you will see that there’s a JVM arg that some are recommending.

-Dlog4j2.formatMsgNoLookups=true

That arg’s usefulness depends on the log4j version in use, and so depends on the CF version.  For now, it’s the best option it seems we have.

(Beware in concluding that old CF versions have older log4jlibraries that are therefore “not vulnerable”. There’s contending discussion going on in the CF and IT world about whether “old” log4j versions–before 2.0–are “not vulnerable” or can’t be declared as such because the Apache team responsible no longer supports them and so are not saying either way. I can confirm that I have added this jvm arg to older CF versions (2016, 11, and 10), and there was no problem in doing it. What’s unclear is whether it “helps”.)

Second, in the forum thread above you will see that while some are trying to update the log4j libraries within CF themselves, it’s not generally going well.  Adobe has never formally supported our changing things like that. We need to wait for them to handle it)

Updated since original post:

Third, you may hear of people proposing to strip out various classes from the log4j jars, and that too is  not a supported solution nor is it a trivial undertaking. And while some resources propose you can “look for log4j jars”, to determine if you have the vulnerable version’s jar, do beware that java jars can themselves contain jars, so simply searching a given folder in the file system for filename patterns will not necessarily be a “good enough” way to really prove you have “no vulnerable libraries”.

Again, for now, we using CF2021 or 2018 should await an update from Adobe. Those on older versions should consider the above as they seek to try to rectify things on their own, and follow the resources I offered, where others are sharing their experiences.

Why so long for a blog post here?

To be clear, I don’t work for Adobe, but some may regard me as one of the more prolific bloggers here on the CF portal. I’ll note that I’ve been holding off  blogging here (or on my own web site) as I’d hoped instead we might have heard today from Adobe with more on their response to this, and I wanted to leave things at that if it came.

But here we are on Monday  evening (in the US) and there is still no new CF update (again, it could come hours after I write), so I wanted to at least offer SOMETHING here in the CF portal to help any who may come looking for information, and who may not on their own have found those other resources above.

More could be said or may come out in time

I have lots more I could say (like how hard it’s been to find any demonstrated example of CF being exploited–I’ve tried across all CF versions since CF10 and with many java version combinations, and I cannot). But again, like the pandemic, people just want to “be as safe as possible”.

So until you can “get the shot” (Adobe’s fix), you can at least “wear a mask” (use the JVM arg). Or read more about all that’s shared in the resources above, and decide for yourself the best response for your organization. 

Sadly, right now, the smoke still has not really cleared on all this. In time perhaps “science” will prove whether this was even something that CF itself (on whatever CF versions)  was truly vulnerable to. Perhaps it is, perhaps it is not.

I understand why for now, people want to err on the side of extreme caution. And for them, let’s hope Adobe creates an update ASAP.

Getting more help, with this and other security issues

Updated since original post: I have added this section since the original post.

As far as being informed more proactively about this and other security issues, Pete mentions in his blog post that you can also keep an eye on Adobe’s PSIRT team listing of CF security fixes. To be clear, that will only be updated when they DO come out with a fix. As of this writing, when there is as yet no fix, there is as yet no mention of this vuln there.

Also, curiously, that page (of all Adobe product security bulletins) has no offer of the available email notification service which Adobe does offer, where they will email subscribers when they DO provide a security bulletin. Everyone should probably at least sign up for that here.

But how might you know even MORE proactively? Let me also point out–as I did in a comment on the forum thread above–that you should consider purchasing Pete’s  HackMyCF service. He had notified subscribers early Friday morning with a first warning, and then later in the day with still more info. The service also offers more value in assessing specific security concerns in your CF configuration. Again, I recommend everyone consider signing up for that. It’s not a free service, but it’s worth the rather small cost, for peace of mind and great value (every month).

Finally, if you are in a situation where you don’t feel comfortable doing the JVM arg change, which does require a CF restart to take effect, it’s something I can help with via my remote consulting, in as little as a 15-minute block of time. Please note I list this last. This post is not a sales pitch. I add this last paragraph sincerely just for those who “don’t touch” their CF and don’t feel comfortable making even such a “simple change”, for fear that something might break. There are still other consultants who can help with CF troubleshooting, including Pete, and I list them in a category of my cf411 site, CF-oriented Troubleshooting Consultants

For more blog content from Charlie Arehart, see his posts here as well as his posts at carehart.org. And follow him on Twitter and other social media as carehart.