About the log4jshell pandemic, and what CF folks can do about it
You can find lots of info in the CF and IT worlds about the log4jshell (or log4shell) "pandemic", since the news broke late Dec 9. If you have not found those yet, first here's a post I did on the Adobe CF portal yesterday with my thoughts (and a "mask" to consider, especially while we await a formal update, "the shot", from Adobe):
My lengthier post at the CF Portal: Dealing with the recent log4j vulnerability, before Adobe releases an update
I have more that I offered originally in this post here, on my carehart.org blog, but first I want to track recent updates and news since I first posted these two blog entries on the morning of Dec 14:
Update for Jan 11 2022: Adding to the news I shared immediately below ("Update for Dec 28 (and Jan 5)"), Adobe did come out today with a technote offering both news and steps for updating to the log4j 2.17.1 jars (after you have applied the Dec 2021 updates for CF2021 and 2018). The technote is entitled, "Log4j 2.17.0 vulnerability on ColdFusion".
Update for Dec 28: news came out Dec 28 from the log4j team of yet another vulnerability, this time in that latest 2.17 version of their library (see below), which is now fixed by a new 2.17.1 version.
Even now, a week on (Jan 5), I'm not aware that Adobe has come out with official policy on whether we should just update those ourselves. Many are proceeding to, lacking any clarity. See the (very long) CF forum thread on the whole log4j debacle, and the messages of recent days. (But before you go there, you may want to keep reading this post first, to get context for things you will see there.)
Update Dec 21: Adobe has just released a technote, entitled "Log4j 2.16 vulnerability on ColdFusion" addressing the remaining vuln that was in the Log4j 2.16 library which had been implemented with the CF updates on Friday (see below). For those who HAVE applied the CF updates below, you can just drop in the new log4j jars that Adobe offers in a zip there, to replace those put in by the updates. To be clear, this is NOT a short-cut to mitigate the original vuln. You must apply the update AND then implement these updated jars. And note that the zip has 6 jar files as found among ALL the products listed in the technote. Do be careful to ONLY replace EXACTLY the ones indicated in the technote. Don't just copy them all in. More in the technote.
Update Dec 17: Adobe has just released the new updates to ColdFusion 2021 (update 3) and 2018 (update 13) for the log4j vulns (yes, both the recent log4j cve's). More at that blog post.
Update Dec 14: Minutes after I posted this, I saw word that Adobe has offered a new informational resource (still not a fix, but that's due later this week), title Log4j vulnerability on ColdFusion. This technote covers:
- how to handle the situation for now, for CF2021 and 2018 (and related things like the PMT and API Manager)
- how they plan to create an update for these CF versions later this week, Dec 17
- As for older CF versions, they indicate that "ColdFusion (2016 release) ships with Log4j 1.2, which is not impacted." While they make no mention of CF11 or earlier, we can infer (and others can confirm) that this would be true for older CF versions.
- That said, to those on CF2016 or below (11, 10, etc.), don't "wipe your eyebrows in relief". You are also missing any sec fixes Adobe HAS added to later CF versions while those were supported. Any of those might be more serious and/or more likely to be exploited than this one, believe it or not.) This is a good time to tell your stakeholders (so concerned about security) that it's irresponsible to be running on versions of CF older than 2018 or 2021. It just won't get brought up in the broader IT community, so will be easily forgotten. Hackers love that.
Now back to what I had written originally in my post...
Apologies to any who may have wondered why I'd not blogged here sooner (than Dec 14). As I explain in that CF Portal post, I've been waiting for the smoke to clear, and I'd been watching the CF-specific community resources that I point to in the post. I was especially hopeful we'd have a formal update from Adobe to report. Lacking that, I wanted to share more.
And in that post I also share more about frequent questions and other "solutions" that folks are considering/attempting. I also share my observation about how I and others have as yet been unable to demonstrate that CF is even vulnerable to the exploit, even having the "vulnerable" log4j library (and I express how I appreciate that stakeholders don't want to hear that: they want a mitigation, which is offered). Finally, I end the post with various resources and services to help you with this and future such issue.
As I say there, when Adobe provides an update, I will update that (and this) post to point that out. Until then, we wait, and do what we can for now, each making the best choices for themselves based on the info that we have.
For more content like this from Charlie Arehart:
Need more help with problems?
- Signup to get his blog posts by email:
- Follow his blog RSS feed
- View the rest of his blog posts
- View his blog posts on the Adobe CF portal
- If you may prefer direct help, rather than digging around here/elsewhere or via comments, he can help via his online consulting services
- See that page for more on how he can help a) over the web, safely and securely, b) usually very quickly, c) teaching you along the way, and d) with satisfaction guaranteed
I guess they were waiting for your blog post first :-)
So we may need yet another cf update (the booster). Oy.
Then there's confusion in the Adobe technote about cf2018, about whether yours includes log4j 2.9 or 2.13. If the latter, the jvm arg helps with the current major vuln. If the former, they are offering an updated log4j 2.9 you can drop in, that tweaks the underlying jar ("the mrna").
My reference to this as a pandemic in the title is becoming only more and more accurate. Time will tell.
To be clear, for now, Adobe does not support just "just updating" our log4j jars to any version, but their update would handle that (and anything related that would need to change in cf due to that). Perhaps it may be that with that work Adobe does to enable the 2.15 log4j jar, it may then be "safer" to have us just drop in the 2.16 log4j jar.
What a mess (and all potentially for a risk that is actually minimal, if somehow no one can still demonstrate whether we can even FORCE an exploit with our own code trying to "inject the virus into our veins"--let alone a bad guy somehow "make it happen". But again, I know: stakeholders want to know you've put on the mask or gotten the shot.)
Again, let's see how the dust settles.
Technically, there are many lib folders beyond this one, but not all matter (any you find in hf-updates subfolders, for instance).
Another complication is that, as the Adobe docs states, you may have implemented your own 3rd party Java libraries which may have their own log4j versions.
It's a mess. But this should answer the question you've raised. Let me know.
Instead, read the technote they had released last week, which I'd linked to above (the Dec 14 update near the top), where they at least confirmed cf2016 was not vulnerable to the major flaw. That's "some" good news for you.
But is that (and any still earlier) cf version vulnerable to older log4j "1" vulns? Sure. And there are various sources talking about how you can remove vulnerable class files (like jmsappender) from within older log4j 1.x jars, if you want to be extra safe or satisfy stakeholders.
Note that such older CF versions are ALSO vulnerable to many other vulns fixed only in later cf updates. Sadly, you may have 10+ years of other vulns, some far more serious than this. See especially my recent post on a ransomware vuln in cf9 and earlier, totally unrelated to this log4j debacle.