Tomcat 8 Vulnerabilities in CF 2016

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.

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 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.

Thanks!

-Doug

According to mulitple articles that I've read, I believe you can prevent it by blocking external access to port 8009.

https://www.trendmicro.com/en_us/research/20/c/busting-ghostcat-an-analysis-of-the-apache-tomcat-vulnerability-cve-2020-1938-and-cnvd-2020-10487.html

https://www.synopsys.com/blogs/software-security/ghostcat-vulnerability-cve-2020-1938/

https://blog.vulcan.io/what-is-the-new-apache-tomcat-vulnerability-ghostcat-cve-2020-1938-and-how-to-fix-it

https://www.zdnet.com/article/ghostcat-bug-impacts-all-apache-tomcat-versions-released-in-the-last-13-years/

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 cfsup@adobe.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.