I read the security bullitins around this jar file coming up in security scans. I noticed that in one of my instances (test) for whatever reason that log4j.jar file is completly missing in the /jetty/lib/ext folder but yet the CF server is running fine. In our dev/prod instances though the log4j-1.2.17.jar is in the /jetty/lib/ext folder and can't be deleted or renamed becasue its in use even when the CF server is stopped.. I guess the question here is 1. Why would it be missing on one server but not the other (Identical deployment; Same versions; etc.). 2. Can these log4j versions be ignored as vulnerable. I know in previous discussions only certain CVES are mentioned but our scanners pick up reference to the jetty instance being vulnerable to.
The jetty folder is for the cf add on service (solr / cfhtmltopdf) , not cf itself. If someone removed the log4j-1*.jar from that jetty folder, it would not affect cf at all.
It may be that someone removed that on the one instance as a mitigation. If you don't need to use the cf solr or cfhtmltopdf features, you could remove that log4j jar. It's not easy to "unstall" entirely the add-on service folders/files, if they are installed as part of the cf installation. You can set the add-on service to be STOPPED, again if you don't use its features.
As for your being unable to delete the files, that would also be possible once the add-on service is stopped.
(For the sake of completeness, there is an available download /installer that would implememt this add on-service, which would be in a totally spare folder from cf.. That COULD be easily uninstalled.)
That's indeed odd. And worrisome.
My /jetty/lib/ext/ folder actually contains the file ".donotdelete". That, I suppose, is a warning against deleting any of its contents.
The aim of a test environment is to presage any activity that can lead to errors in production. Hence, the test environment must - at the very least - have the capability of your dev and prod environments. That is not the case in your current setup. Which means, your setup isn't optimal.
My suggestion is that you ensure that the test instance's /jetty/lib/ext/ contains the same Jar files as are on dev and prod. For example, by manually copying any missing Jars from the /jetty/lib/ext/ of dev/prod to that of test.
I guess the question here is 1. Why would it be missing on one server but not the other (Identical deployment; Same versions; etc.). 2. Can these log4j versions be ignored as vulnerable. I know in previous discussions only certain CVES are mentioned but our scanners pick up reference to the jetty instance being vulnerable to.
(1) I agree with Charlie's suggestion that someone might have inadvertently deleted the file. But you may then ask, "Why delete on Test, and not on Dev or Prod?". Sorry, me no sabe.
But I can make a guess. Was Test installed perhaps differently from Dev and Prod? For example, the one instance by enabling packages relevant to Jetty, the other instance by launching the ColdFusion_2021_Addon installer.
(2) You cannot and should not ignore a Jar file just because it is vulnerable, Vulnerability doesn't mean avoidance. It means risk. Risk is in turn a sliding scale from 0 to 100%, taking 4 factors into account:
- the probability that your application or security can be compromised. For example, one of the Log4j vulnerabilities involves LDAP. If you don't use LDAP, your probability of being compromised will be very low.
- the impact of such an event on your product or organization;
- the risk you - as product-owner, manager or organization - are willing to accept. For example, following the announcement of the Log4j bug, some developers in this forum simply gritted their teeth and decided to wait till Adobe produced the hotfix.
- the resources you - as product-owner, manager or organization - are prepared to commit to mitigate the risk.
There is another reason why you cannot ignore a Jar file just like that. One word: dependency.
ColdFusion, like any other software, consists of a network of packages and libraries that communicate with and depend on each other. If you remove a package or library, you will likely break a dependency somewhere.
You can get an idea of Jar dependencies by following these steps:
1. Open the Command Prompt as Administrator.
2. Use CD to navigate to the bin directory of the JDK that ColdFusion is using.
3. Run the command jdeps -dotoutput path_to_dependencies_dir path_to_jar_file
[ path_to_dependencies_dir = the path to the directory in which you want to store the dependencies file;
path_to_jar_file = the path to the Jar file whose dependencies you wish to know. Use the wildcard *.jar for every Jar file in the directory. ]
For example, on my installation, the command is
jdeps -dotoutput C:/ColdFusion2021/cfusion/jetty/lib/ext/jar_dependencies C:/ColdFusion2021/cfusion/jetty/lib/ext/*.jar
The dependency files are stored in the jar_dependencies directory, and can be viewed with a text editor. I am assuming you will have copied the missing Jars into Test's /jetty/lib/ext before running the command.
Thank you so much.
It sounds like you may feel things are resolved. If so, great.
Can you help us and future readers with a bit about what you found and have concluded?
We had 2 different server admins run the installers between our enviornments and found that on the one with out the jars no additional services were selected (SOLR and pdfhtml particularly) during install. When we removed those services via re-install it kept the jetty folder from re-appearing with the affected jars. The patched one via HF3 still does appear in the rollback files and patched to 2.16 in cfusfion/lib which although is a concern isn't as concerning as the ones identified in the jetty folder. Thanks again for all your assistance.
Thanks for clarifying. It would seem my first reply should be marked as an answer then, to help save readers having to read all replies. Would you agree? (Some people just mark answers for others, but I prefer to have the asker make that indication, if they would.)