November 4, 2022

Tomcat Patching Best Practices

Tomcat

By

Patching Apache Tomcat is a necessary step to keep your Tomcat deployments secure and performant. Tomcat patches can protect you from CVEs, and allow you to keep up with the current code base while maintaining your configuration until it’s time to upgrade to a new branch.

In this blog, our expert explains when to patch Tomcat vs. when to perform an upgrade, the vulnerabilities that have affected recent versions of Tomcat, and how to test Tomcat patches you have installed.

Tomcat Patching: Why It's Important

First, a clarification: when we say “patch” in Tomcat, we are referring to an upgrade within the main branch of Tomcat that is being deployed. For example, if you are running Tomcat 8.5, and then a new version, 8.5.X, comes out, to upgrade from 8.5 to 8.5.X would be considered a patch, even though technically it’s a new version within the same branch. On the other hand, if you went from Tomcat 8.5 to 9.0, that would be considered upgrading versions to a new branch.

When patching, you’re typically able to keep your previous Tomcat configuration while still getting patches and security updates. If you perform an upgrade to a new branch, you’ll have to re-do your configuration because the changes will be so drastic that your previous configuration will no longer be compatible. In other words, patching allows you to address important issues and keep up with the current code base for the version of Tomcat you’re using.

Patching Tomcat vs. Upgrading Tomcat

Patching is a good practice because it keeps your Tomcat deployments up to date and prevents a large gap in between maintenance windows of the Tomcat server. It should be done whenever possible, but especially in instances in which a CVE is being addressed by the patch.

Patching is the best way to keep your Tomcat deployments secure in between upgrades. Because Tomcat branches typically last for around 10 years, you will likely have far more instances of patching than upgrading. A Tomcat upgrade is only necessary when a branch of Tomcat is being sunset by the community, meaning it will no longer be supported. When that happens, it is time to upgrade so you don't miss out on security and feature updates, or become vulnerable to CVEs. 

Tomcat Security Risks

There are a number of existing CVEs on all three of the supported major versions of Tomcat (Tomcat 8, Tomcat 9, and Tomcat 10). These range from cross-site scripting attacks, denial of service attacks, bugs found in components being used by Tomcat itself, and more. Let’s examine what happened with the HTTP Request Smuggling vulnerability that was discovered in May of 2021.

This CVE ended up affecting Tomcat 8.5, 9 and 10 all at once. The vulnerability caused incorrect parsing of HTTP transfer-encoding request header. This led to the possibility of request smuggling when being used with a reverse proxy. The reason this was a possibility is because vulnerable versions of Tomcat did not correctly parse the HTTP transfer-encoding request header in some situations. Not parsing the request header based on specification leads to the possibility of request smuggling. Tomcat would incorrectly ignore the transfer encoding header if the client declared it only accepts an HTTP/1.0 response.

In this example, the solution for this issue was to patch to the next version that addressed this vulnerability. If you didn’t, you would remain susceptible. It's worth mentioning that this is the case for almost all open source technologies, not just Tomcat. Unlike with commercial software, there are no traditional patches (i.e. Windows providing security updates); you get the fix in the next version of Tomcat that comes out. If you’re lucky, you can patch to the same branch, but if the version of Tomcat is one that is no longer supported by the community, you’re then forced to perform a full upgrade which is more resource-intensive.

Read more about Tomcat security >>

Looking For More Tomcat Tips?

The Enterprise Guide to Apache Tomcat includes best practices for Tomcat performance, configuration, security, resilience, and more.

Enterprise Guide to Apache Tomcat

Download free copy

How to Test a Tomcat Patch

The best way to test out a Tomcat patch is in a testing environment. First, acquire the binary or source of the version to which you want to patch. Then drop in your current configuration and see if it happens to work. The odds are good that if you’re in the same major branch, there shouldn’t be anything that would keep it from working.

You will need to do some testing for both patching and upgrading, but it should be significantly less for patching. Time is of the essence, however, as you are more likely to run into issues the longer you wait in between patches.  

Tomcat Patch Management Best Practices

It’s important to keep an eye on Tomcat news for security updates, new version releases, end of life announcements, and more. Staying in touch with the community and being on their mailing list is a great way to keep yourself informed, plus it gives you an avenue to pose questions to the contributors and developers.

The rule that we try to emphasize to OpenLogic customers is patch as often as you can, and upgrade when you’re forced to. Upgrades eventually become unavoidable, but patches are something that require a little more diligence to keep your Tomcat up to date. Planning maintenance windows so you have time to patch is highly encouraged.

Need Technical Support for Tomcat?

If you need help planning a migration or are short on Tomcat expertise in your organization, OpenLogic is here to help. Talk to an expert today to learn more about how we can support your Tomcat deployments. 

Talk to a Tomcat Expert 

Additional Resources

 

image-zend-blog-author-bio-andrew-pomponio

Andrew Pomponio

Associate Enterprise Architect, OpenLogic by Perforce

Andrew's areas of specialization include networking, Linux, network security including OpenSSL, and operational troubleshooting. He has been working in the industry for over seven years and is acquiring new skills every day.