Vulnerabilities in CF application files

[wtlaughlin]

I am running a CycloneDX security scan on the latest ColdFusion 2021 Enterprise WAR file for my application (HF22). I am getting 160+ vulnerabilities reported, most of them either Critical or High. I have some questions about these:

1. Most of these seem to be related not to the actual libraries in /cfusion/lib, but to the JAR files in /bundles/repo, e.g. ehcache-2.10.3.jar, jackson-databind-2.9.8.jar. I don't know what (if anything) I can do to fix these. Can I delete the most vulnerable files without killing the application server? Does anyone have any advice?

2. A number of the other vulnerabilities are being reported in libraries that aren't necessarily in use in my deployment: they're part of the hotfix installer JARs in /cfusion/hf-updates or /bundles/updateinstallers. Can I safely remove the most recent hotfix installers from these directories, once the hotfix has been installed and tested? (I have no intention of uninstalling a hotfix from Production: if necessary, I will backtrack to a previous Azure deployment slot.)

3. Another source of vulnerability notices is the file /cfusion/jetty/webapps/solr.war  I did not think I had the Solr module installed, but if I remove this WAR file it seems to break my PDFs. I am not using the htmltopdf tag specifically, and the PDF module is installed on its own; but after I remove solr.war PDFs fail with the messsage "cannot find implementation class tagext.document.DocumentTag". Does anyone have experience with this? Is it a Solr dependency issue, or is this just a red herring with the issue possibly occurring somewhere else?

I hope this isn't too scatterbrained. It all seems related to me. Anyway, thanks in advance for any advice anyone can give me.

[Charlie Arehart]

WT, first let's acknowledge that a problem with such sec scan tools is that they rarely have any understanding of the applications being scanned: they simply look at ALL files within a given folder or file system to see if any are what they regard to be "vulnerable"--even if happens to be that the file is not being (or perhaps can't even be used) by that app. But I appreciate that some who mandate use of the scanning tool don't care about that. 

So to your point 1, the files in the bundles/repo relate specifically to CF PACKAGES, the new modular bundling of cf functionality introduced in cf2021. And more important, the files there are either for packages that are or are NOT installed (within cf), and also for different VERSIONS of any given package. And these libraries are often not files Adobe created but rather jars that cf bundles for use with such packages.

As such, there may well be files your scans finds which Adobe UPDATED (perhaps even for the sake of security), but they don't DELETE them simply because they were vulnerable. The intent is that in updating the package, the old files are no longer "used" by cf.

So sadly, no, there's no mechanism to have cf REMOVE the files in the repo that may no longer be in use; nor is there a mechanism to help you decide what could be removed. An extreme response would be to try to identify what jars are used by what packages that ARE installed (via the cf admin, cfpm, or studying config files), and remove all else. I don't know of anyone having done that, and there may be more dependencies than can be determined completely even by those means above.

Consider filing a feature request that asks Adobe to improve this. 

To your point 2, the same applies. But as you note, if you don't ever plan to uninstall your current update, you could delete those hotfix jars.

Even so, note as well that when an update is applied, the update creates a backup of many files used to DO that uninstall of an update. Someone with your concern and intending NEVER to uninstall the current could technically delete the files on that backup folder...but again there's not a "feature" that does it.

3) Finally, no, there's no connection at all between the solr.war and the pdf generation. Now., technically, that war comes with CF if one told the cf installer (or war builder) to include solr. And both the solr.war and pdfg web app are siblings that one can install as web apps in cf (or your preferred jre app server). But they're not otherwise connected TO each other.

So it would seem that there HAS to be some other explanation for what you're observing. 

How did you create your cf war? There are multiple ways one can. 

[wtlaughlin]

Thank you, Charlie. I generally create the WAR files using jar -cvf from the Windows CLI.

Also, I understand about the security scanners being uncritical of the actual use to which the libraries are put, but that (unfortunately) doesn't mean the people at the other end of the scan reports won't yank my application from Production if they feel the reports look bad enough on paper. That's why I'm trying to mitigate anything I can. However, as you point out, that requires a lot of detective work and may result in unintended consequences if I don't get the dependency tree exactly right...

As for Solr and PDF, I have noticed that sometimes after an update a module that says it's installed will behave as though it isn't. I'm remembering now that that happened to me with the PDF module in HF21; however, the update I was working from, from which I deleted Solr, had previously worked just fine for PDFs (though SQL Server had initially disappeared). I will try forcing a reinstall of the PDF service and see where that takes me.