Tomcat update because of vulnerability CVE-2020-1938

Hello @fcrocnoc,

Yes, I am happy to report Tomcat 8.5.51 has been included with Jamf Pro 10.20.0 Beta 2.

It is clearly not sufficient to provide a new version of tomcat with Jamf Pro 10.20. What is needed is an updated tomcat version for all versions of Jamf Pro that have a vulnerable tomcat version. You have to assume that organisations can not easily update their jamf pro version on the fly. If the vulnerability id as bad as it sounds we also can not wait until Jamf Pro 10.20 comes out - we would need a fixed version of tomcat asap.

Our JAMF Pro environment is not a very big one. So we can afford a upgrade to JamfPro 10.20, but we cannot afford to install a beta. When will JamfPro 10.20 will be officially released? If this takes to long (lets say more than one week), I agree with @mschroder, and we would also need a fixed version of tomcat asap.

Have to agree with everyone else here. That applies to your product just like any other product on the market. Forcing a full product upgrade is not acceptable. You should be issuing a patch for the issue.

This only impacts if AJP is enabled... shouldn't AJP be disabled in Jamf Pro installs?

Edit 2/26: Updated Risk Assessment

Thanks for the comments and concerns on this vulnerability. No action is needed at this time related to this issue. While the AJP connector at the root of this CVE is not used by Jamf in our various Tomcat configurations, there are cases where it could be exploited to return config file information for on premise customers.

Action may be required for customers running on-premise to mitigate this issue as it poses a potential risk of returning config files in the case that the default AJP port is accessible to untrusted networks. Our recommendation would be to either comment out the AJP connector in server.xml and restart the Jamf Pro Tomcat service OR disable port 8009 on your firewall. The issue will be fully resolved in 10.20 which has a planned release date of March 17th.

As a standard practice, Jamf includes the latest version of Tomcat available bundled in our installers at time of code cut for each major build. The upgrade to Jamf Pro 10.20 will resolve this CVE when it is made publicly available.

The administrative guide on tomcat versioning can be found at: https://www.jamf.com/jamf-nation/articles/380/apache-tomcat-versions-installed-by-the-jamf-pro-installer

This issues impacts on premise installs of Jamf Pro only. This issue does NOT impact Jamf Cloud, Jamf Now, Jamf Nation, Jamf School, or Jamf Protect

FWIW, we comment out the Tomcat AJP connector as per: https://github.com/dataJAR/Reference-Kubernetes-Build/blob/master/build/jss/config/server.xml#L90-L103

I wish jamf would be more proactive and if their product creates a vulnerability for on prem customers, proactively email those customers and say "until 10.20 comes out, you may want to consider commenting this out of your server.xml."

Consider voting up this feature request for better communication from jamf on stuff like this - https://www.jamf.com/jamf-nation/feature-requests/9226/jamf-needs-to-be-more-proactive-alerting-customers-on-vulnerabilities-that-exist-from-installs-of-their-product

It is good to hear that a standard on prem install is expected not to be vulnerable. I am still a bit surprised that the Connector is active by default. After all the tomcat installed is fully tailored for jamf, and the connector is apparently not used. So why is it not commented out by default?

@mschroder I have updated our risk assessment based on new information and testing. In cases where the AJP port is open to untrusted networks in on premise installs, there is a risk of file read. Our recommendation would be to either comment out the AJP connector in server.xml and restart the Jamf Pro Tomcat service OR disable port 8009 on your firewall. The issue will be fully resolved in 10.20 which has a planned release date of March 17th.

Got email from jamf, thanks for the communication jamf team!

Yes, it is good that jamf have done a deeper analysis now and also contacted users directly. I still would prefer that jamf would become more pro-active and not wait that users bring an issue like this to their attention. Jamf distributes tomcat in their installer package, they must have an eye on issues related to the tomcat versions they have distributed and actively check whether these issues have an impact on the reliability and security of the jamf software stack, and warn users as soon as possible. We have to be very grateful to @fcrocnoc for having raised the alarm on this one.

agree. They're seemingly trying to be more security focused (announcing jamf protect), they should 100% be more proactive in all area of security. Wouldn't hurt if they also invested in patch improvements, too, so that customers could better utilize the product to secure their environments.