2 Correct answers
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
...
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 jet
...
7
Replies
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.
Possible solution:
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.
CVE 2020-9488
CVE 2022-23302
CVE 2022-23305
CVE 2022-23307
By @christopher.jazinski
My answer:
(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.
AdChoices