[Looking for Charlie's main web site?]

About the log4jshell pandemic, and what CF folks can do about it

Updated later Dec 14, 17, 21, 28, then Jan 11. See more below.

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:

[....Continue Reading....]

Comments
Thanks for these details. And looks like just after you published that Adobe shared guidance on the log4j vulnerability https://helpx.adobe....

I guess they were waiting for your blog post first :-)
Thanks, Michaela. I did update the post shortly after I wrote it, to link to that. I am just seeing your comment. We may have been writing at the same time. :-) I do appreciate the heads-up.
I'll note that yes, there's a new variant ("omicron"), fixed in a new log4j 2.16, that may not be resolved with the mask (jvm arg) or the shot (the update due Friday) which was due to implement log4j 2.15.

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.
How can you tell for cf2018, whether your installed version includes log4j 2.9 or 2.13?
# Posted By Lauren | 12/16/21 8:05 AM
Search for log4j*.jar files, primarily in the cfusion/lib folder. (If you are on other than cf standard and may have implemented more than one cf instance, then each instance has its own sibling to cfusion, and its own lib.)

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.
Does this latest issue affect ColdFusion V8 using Log4j.jar 1.2.12? We are retiring an old web app running on an older version of CF.
# Posted By Chuck | 12/21/21 11:13 AM
Chuck, no, nothing Adobe offers as an update will apply to cf2016 or earlier, as those are no longer supported by them.

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.
Copyright ©2024 Charlie Arehart
Carehart Logo
BlogCFC was created by Raymond Camden. This blog is running version 5.005.
(Want to validate the html in this page?)

Managed Hosting Services provided by
Managed Dedicated Hosting