after update is it safe to remove/rename older versions of log4j-1.x.x from server?
After installing Hotfix-013-329786 the java class path still shows an entry for
/ColdFusion2018/cfusion/lib/log4j-1.2.15.jar
Is it safe to delete these older versions from the server?
Newbie
5 posts
Thanks Charlie!
On a related but separate question, is it alright to remove the hotfix backups several versions back so the vulnerability scanners do not find possible old-vulnerabilities there (or does Adobe also remove the vulnerability from the backup first)? My expectation is that we would not roll-back to a vulnerable version if the last hotfix is stable and several months old.
Thanks again!
It is indeed safe to delete (or I would recommend, archive/move off the server) the hf-update subfolders beyond the very last update installed. It’s that last one which would be used to uninstall the current release (by restoring what’s in its backup folders). I’d recommend archive vs deleting them because there is sometimes value in being able to look at what had been in those prior backups, the update’s logs, etc.
And no, to be clear Adobe does NOT modify the log4j jars in those backup folders as part of the update process (because that would fly in the face of that point above, about how restoring from the backup folder brings things back to as before the previous update).
I suppose someone could argue that Adobe “should have” modified the log4j jars in the backup folders, but honestly that would be pointless: for one thing, they are not in any way web accessible (so the fact that scanners would still bark about them is really overkill). But second, if they still had the same 1.x jar file name, then scanners would still find them.
As I said, smart scanners should see if the log4j 1.x jars have the vulnerable classes. If they do not, then they should not be flagged as being vulnerable to log4jshell. Sure, they could still flag them (with less severity, it seems) for just being “old and no longer supported”.
Again, my hope is that in the long run Adobe WILL update CF2021 and 2018 so that they no longer have ANY reliance on those 1.x jars. But even then we will still have even this most recently modified log4j 1.x file (from the Dec 17 updates) in the backup folder once we implement the NEXT update.
But bottom line, yes, you can remove the hf-updates subfolders, though I’d leave the last one–which will still have this unmodified log4j 1.x file. If one really wanted to, they could rename that (so as to “fool” the simpler scanners), but I just fear that could comeback to bite folks if they later do an uninstall that relies on that subfolder, and it may use a hard-coded list of what to restore and will now NOT find the log4j 1.x file that it wants.
Quite a mess. But let’s not blame Adobe entirely for it.
Indeed, even Adobe indicates in their technotes for the updates that there are no known instances of this vuln being exploited. The whole IT world may reasonably fear that there could be “any java app” which could be vulnerable, but it just seems that CF is not, at least not inherently, nor even if we SPECIFICALLY try to log the vulnerable log4j $ strings in either cflog/writelog or by passing things to what CF logs itself.
But stakeholders (and scanners) don’t want to hear that. They want it to be “gone”, and that all should take every measure to eradicate it. If only it were so simple. But this all goes along with our current culture and its response to the other pandemic.
Austin, no, you cannot just remove that jar in CF2018, left there after update 13. If you do, CF will start but will not be able to run any cf templates. But there’s some good news on this, and other related “news” I can share.
1) First, some good news: note that this jar WAS indeed modified by that update 13, to remove the vulnerable classes. You’ll see that the date modified for the file is in fact the time you ran the update, indicating that Adobe “put it in place” in that update. (And if you were to do a comparison of the jars between that and what you find in the corresponding “backup” folder in the hf-updates subfolder for update 13, you could see how the jars differ in this important way.)
2) That said yes, vuln scanners which only look for log4j 1.x jar filenames will bark about it. Smarter ones would see the vulnerable class is gone.
While you COULD rename the file to placate them, and cf would still run ok (Java really doesn’t care about jar file names), that could cause confusion when a later cf update might literally remove the use of log4j 1.x in cf2018, and that will try to remove the jar (of the expected name) but won’t remove the one you renamed!
3) And yes, some folks would want to point out that the existence of any log4j 1.x jars or classes should be removed by Adobe, as log4k 1.x is no longer supported by the apache group and has still other vulns. Again, my hope is that Adobe WILL indeed remove it (and also the one in cfusion/jetty/lib which was NOT modified in the update) in a later cf2018 and 2021 update.
4) Finally, to those who may find this and are on cf2016 or earlier, as you may know those are no longer supported by Adobe. They won’t be updating those.
You also cannot simply REMOVE the log4j 1.x jars, nor has Adobe discussed if it’s OK to UPDATE them to 2.x. But consider how even in cf2018 you can’t currently “just remove” the 1.x jars.
Your best recourse is to move to cf2018 or 2021. (Reach out to david@fusion-reactor for a special deal to get the cf upgrade price even on such older cf versions.)
Until you do, your only other recourse to address this log4jshell issue (in the 1.x jars of cf2016 and earlier ) is to remove the vulnerable classes. Adobe did document this process for other “third-party libraries” one might use even with CF 2018 and above. See the discussion with the steps for cf2018 in their first technote on the log4j issue:
https://helpx.adobe.com/coldfusion/kb/log4j-vulnerability-coldfusion.html
(The other aspects of that page were indeed superceded by the subsequent cf updates released a few days later, on Dec 17.)
You must be logged in to post a comment.
23 Nov
10AM Pacific
Online
