Are there plans to update CF 2016 to address Tomcat vulnerabilities? Our customer has run Nessus scans on the server running our ColdFusion instance, and it's identified several Tomcat vulnerabilities, which are causing some concerns with the customer.
CF 2016 with update 16 is currently using Tomcat 8.5.42. According to the Nessus scans, Tomcat should be upgraded to 8.5.58.
Doug, yes, Adobe is aware of the fact that the Tomcat version is out of date and missing security fixes.
To be clear, they do often update Tomcat within updates to CF. The last such Tomcat update within CF was in the Sep 2019 updates for CF2018 (update 5, which brought its included Tomcat version to 9.0.21) and CF2016 (update 12, which brought its included Tomcat version to the 8.5.42 you refer to).
That said, it is indeed lamentable if not irresponsible that there's not been another Tomcat update within CF in over a year.
FWIW, there was at least an update in March 2020 to each of CF2018 and 2016, to address what was known as the "ghostcat" vulnerability in Tomcat which became widely known in earlier 2020. So it's not like they are ignoring Tomcat security issues entirely. Still, at that time some of us pressed Adobe on why they did not take that chance to update Tomcat at that same time, now over 6 months ago.
And so yes, scanning tools like Nessus as well as Pete Frietag's hackmycf checking tool (https://foundeo.com/hack-my-cf/) have been reporting this critical need of further updates to Tomcat for at least several months.
As a "workaround", someone may want to point out that it's certainly possible for one to install Tomcat themselves, and run CF on that as a WAR file. It's a bit more complicated to set things up than the normal "server" deployment of CF, but it is indeed an option. And then YOU would control the version of Tomcat rather than Adobe. But note that deployment of CF as a WAR file is a feature only in CF Enterprise, not in CF Standard.
Folks who want to express concern about this state of affairs should address Adobe directly about this. They don't tend to interact here. It's not clear if they even see posts here. One address you could try is email@example.com. And if you or they get clarification on firm plans for a coming Tomcat update, it would be great to see that offered here, if you may point them to this post.
If nothing else, I hope that in some future update of CF Tomcat WILL again be brought up to date, and that someone may pop in here to point that out for future readers of this post.
Thanks for the info and for the suggestion to contact ColdFusion Support. I've sent the question to them.
According to mulitple articles that I've read, I believe you can prevent it by blocking external access to port 8009.
James/jamo, I appreciate what you're offering but I do think you have misconstrued things. (I can't tell if you're replying only to the OP, Doug, or also to my first reply.)
But to be clear, we using CF don't need to do any of that, if we just apply the CF updates from March 2020 (that I mentioned above), which do address that "ghostcat" issue. As such, I don't think that's what Doug was talking about.
Instead, Doug was referring to how the Tomcat within CF is several releases behind. And several of those updates to Tomcat addressed security vulnerabilities which people would want implemented. (Those can't generally be solved by any workarounds, but just by Adobe updating the Tomcat within CF.)
To be more specific, there is a page listing Tomcat updates that address security issues, and here are links to those (for Tomcat 8) that have been offered since the Tomcat version currently offered in CF2016, 8.5.42 (at least since the CF update of Sept 2019 which upgraded to that):
And there's a similar list for Tomcat 9, with those new since that last Tomcat update Adobe did for CF2018 also in Sep 2019.
So again, what's needed is for Adobe to get Tomcat updated for us (like they last did in those updates of Sep 2019), and some are important enough that more and more tools or people are finding this disparity and worried about it.
Charlie, thanks for the additional links.
We use a cloud-based WAF service and our framework is daily scanned for PCI compliance. Thankfully we haven't received any notification regarding Tomcat vulnerabilities "yet".
What do you have to do in order to bleed information regarding the version of Tomcat being used? Did they trigger a default CF error, identify the version of CF used and then assume that a certain version of Tomcat was being used? Or was additional data leaked using port probes? (Our web application servers only allow external access to ports 80 & 443.)
We're going to evaluate the Hack-My-CF service to determine what it's capable of detecting.
I don't believe there's any url that can be used to detect the tomcat version, if that's what you mean.
If you may wonder how the nessus scan Doug is referring to might detect it, that could be something running ON the server, or with direct access to its files, in which case yes something could detect the version (from files within cf and tomcat).
If you or anyone else wants to press that question, I'd recommend you run it by Pete F at foundeo.com, as he tends to be on top of such possibilities. HTH
I checked using Hack-My-CF and they use a CFML "probe" script to report on all of the internal CF-related files (MD5 hashes) and server related variables. I don't believe that they perform any external tests to determine if Tomcat can actually be connected to and/or compromised.
The regular Nessus Pro is kinda pricey. I'm going to evaluate the free "essentials" version (scans up to 16 IPs) and see what it discovers when scanning a CF2016 server.
James, I just want to clarify that I knew that already about hackmycf. My last response was replying to your previous one, asking how cf might "bleed info" about tomcat version info. Since Doug had been using nessus, I read your question as you asking about that, which is why I responded about nessus.
Sorry, I thought you knew already that hmcf worked based on a probe that one installs on cf (but it does also make calls from the outside, as one may notice with CF monitoring tools or access logs).
HMCF is a great tool, for many reasons, and as I'm quoted saying on the site, I think everyone should get it.
Thanks for the comments Charlie and Jamo!
I contacted CF Support yesterday and they suggested that I send details to the Adobe Product Security Incident Response Team. I've sent details to them, and they've opened a case.
Man, if that gets it done that will be stunning (to think that it had to be pushed that way, when it's seemingly obvious that they'd know they'd not updated Tomcat in a year, and that there were multiple vulnerabilities).
But it does seem that sometimes the CF Team needs (juggling many priorities, of course) to be forced into action by the Adobe Security team (PSIRT). It should not be that way for significant issues that should be generally known, but it seems it sometimes is.
If it's the case here, then good on you, Doug, for pressing it with them (and here). It doesn't change my thought on the first sentence of my original reply. I guess a difference may be "who" at Adobe knew. Surely the CF team knew, or at least somebody, as they HAVE updated the Tomcat underlying CF, as recently as last Sept. I didn't consider that the PSIRT might not already know it was so out of date. I guess if that team is more "responsive" than "proactive", or if they only focused on "vulns in CF specifically" rather than "vulns in Tomcat, which underlies CF", it would take us pressing them. I am just surprised that it should.
Perhaps someone from the CF team will get back to us here on this. Or certainly if you learn something, Doug, please do let us know.
What type of Nessus scan did your client run? I downloaded the free Nessus Essential and performed an external discovery & web application scan. Nessus wasn't able to even determine that ColdFusion was used or that Tomcat was used. We externally scanned an origin IP as well as the cloud-based WAF/DDoS-protected IP. (We use IIS. Would that further mask that Tomcast is being used?)
Was the scan run "internally"? If so, it probably was capable of detecting more as it had greater access than most external scanners would.
I'm not sure what the Nessus product is called, but it is run "internally" and seems to run a filesystem scan, looking for vulnerabilities.
Hope that helps!
I am Alex from Adobe's PSIRT team and I wanted to provide some information regarding your Twitter question about the Tomcat vulnerabilities in ColdFusion 2016. The below list contains all the CVE's of Tomcat after 8.5.42 which CF is using.
Please let us know if you have any questions or concerns and we would be happy to address them.
Moderate: Local Privilege Escalation CVE-2019-12418 (Fixed in Tomcat 8.5.49):
ColdFusion doesn’t use JMX Remote lifecycle listener, also we don’t ship this listener class with 2016 ColdFusion. ColdFusion is not impacted by this tomcat vulnerability by default.
Low: Session fixation CVE-2019-17563 (Fixed in Tomcat 8.5.50):
The exploitation of this vulnerability doesn’t look to be practical. Also, by default CF doesn’t make use of Tomcat’s form authentication unless customer configures form authentication explicitly. ColdFusion is not impacted by this tomcat vulnerability by default.
Important: AJP Request Injection and potential Remote Code Execution CVE-2020-1938 (Fixed in Tomcat 8.5.51):
ColdFusion is impacted by the vulnerability and we have already fixed this issue in ColdFusion 2016 update 14 https://helpx.adobe.com/in/coldfusion/kb/coldfusion-2016-update-14.html. We have baked in the fix into ColdFusion shipped tomcat. Also, if customer has applied lockdown on CF servers this vulnerability can’t be exploited.
Important: Remote Code Execution via session persistence CVE-2020-9484 (Fixed in Tomcat 8.5.55):
ColdFusion is not making use of Persistence manager. We only replicate sessions by default when cluster is configured. Also, the vulnerability is very difficult to exploit as it requires the ability to control the files over server to exploit the same. ColdFusion is not impacted by this tomcat vulnerability by default.
Low: HTTP Request Smuggling CVE-2020-1935
Low: HTTP Request Smuggling CVE-2019-17569
The exploitation is unlikely as even tomcat written such reverse proxies are unlikely. If the customer is behind web server, the parsing will be done by Apache/IIS before passing it to tomcat via AJP and makes CF not vulnerable.
Moderate: HTTP/2 request mix-up CVE-2020-13943 (Fixed in Tomcat 8.5.58)
Moderate: HTTP/2 DoS CVE-2020-13934 (Fixed in Tomcat 8.5.57)
Important: HTTP/2 DoS CVE-2020-11996 (Fixed in Tomcat 8.5.56)
These vulnerabilities are in either http/2 connector or during an upgrade from http1.1 to http2. ColdFusion by default not configuring any HTTP/2 connector. Also, if the customer is using Apache/IIS over CF connector only AJP connector gets used. ColdFusion is not impacted by this tomcat vulnerability by default.
Important: WebSocket DoS CVE-2020-13935
We are starting a websocket container when starting tomcat but couldn’t be able to find any possible exploit vector. CF doesn’t use tomcat websocket functionality. CFWebsocket uses netty as a websocket server (not tomcat) for serving websocket requests.
Thanks for posting that info. Alex had sent the same list to me, and I was waiting for Alex's permission to post it here. But you beat me to it. 🙂
I'm really impressed with the PSIRT team's responsiveness. Kudos to them.
That is indeed great to see the response here from Alex of the Adobe PSIRT, on why they have made the decision that the Tomcat 8 underlying CF 2016 need not be updated. And we can assume he'd say the same regarding Tomcat 9 (which underlies CF2018), if all the vulns are indeed the same.
Of course, for someone whose Nessus scan (or HackmyCF scan) reports that Tomcat is so outdated, such tools won't know about this discussion, but it's good that we can point interested people at them.
All that said, it would still be great if some future update of CF would simply upgrade Tomcat the way that CF updates did in Aug 2019. Then at least it would not seem "so out of date".
Even better would be a new CF installer, that incorporated that, as well as the needed June 2019 CF update for the CF Admin update feature to work, and the wsconfig update (for ghostcat) from Mar 2020, so that people don't have to do all those things upon a first install of either CF version today.