About the log4jshell pandemic, and what CF folks can do about it
Note: This blog post is from 2021. Some content may be outdated--though not necessarily. Same with links and subsequent comments from myself or others. Corrections are welcome, in the comments. And I may revise the content as necessary.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:
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.