Edit 12/7/24 - well, this post got a lot more traction than my little blog was expecting. I’ve had a bit of important feedback that the free tier of Ubuntu Pro is much more generous than I expected, so skip to the end of the post for an addendum.
As I run a few services on Ubuntu, I like to keep an occasional eye on the Ubuntu Security Notices website. Yesterday, a USN for Apache Tomcat caught my eye. I run a servlet on Tomcat 9, and I was concerned about the description stating “Tomcat could allow unintended access to network services”.
I am always nervous about exposing a computer to the internet, and that warning is chilling. A USN is often posted in response to a disclosed CVE, and this one was about 18 months old and assigned a score of 7.5 (High) on the US Government National Vulnerability Database.
My Tomcat instance is running in an Ubuntu 22.04 lxd container on an Ubuntu 24.04 host. I tend to run things in containers as it probably adds a bit of security and isolation from external attackers and my own incompetence. Happily, the update notes on the USN show that the package has been patched and released for 22.04:
Phew! So everything is patched and a simple update should suffice?
No! Let’s look at this a little closer:
The package has been patched for Ubuntu 18.04. This is an old Long Term Support (LTS) release from April 2018. Canonical support LTS releases for 5 years as standard, so this release is now beyond standard support. So why is this release getting a patched version? Well, Canonical offer a commercial Extended Security Maintenance (ESM) subscription for some old releases, where support can be purchased beyond the normal lifecycle. Canonical now sell ESM bundled as part of their Ubuntu Pro subscription. ESM for the 18.04 release is provided, for subscribers, until at least 2028. So a “regular” user on 18.04 will not see updates for this (or any other) package as routine support has finished, but an Ubuntu Pro subscriber will be covered. That all seems fair enough.
20.04 is the next LTS release from 2020, and this is still within the regular support window of 5 years. There’s a patched package available to everyone. This seems sensible and rosy (but all is not as it seems).
22.04, the release I’m running in the container, is another LTS from 2022 and is under regular support until 2027. Canonical has released a patched package, but only for Ubuntu Pro subscribers! So an older supported LTS release gets a “free” patched version but a newer one doesn’t?
24.04, the most up to date LTS, doesn’t get mentioned at all. Digging deeper, it seems the version released with 24.04 has never been vulnerable, which explains why it doesn’t appear on this list.
OK, so why would tomcat9 users on 22.04 be penalised compared to 20.04 users? Well, there’s another layer to all of this. Canonical don’t support every package in an Ubuntu LTS release for 5 years. Rather, they support a core of about two thousand packages in the main repository. The remaining 90% of available packages are in the universe repository, and Canonical only support those on a “Best Effort” basis. This means that regular LTS users will only see security updates in those packages if they’ve been fixed by community members, can be inherited from a stable Debian release, or if the vulnerability has some form of exceptional impact which would prompt Canonical to release a fix themselves. However, Canonical do commit to providing security patches for Ubuntu Pro subscribers for all packages, including universe:
Tomcat 9 is in the universe repository, explaining why the patch isn’t available to 22.04 LTS users.
It does seem crazy that Canonical would choose to expend the energy to fix and test a package which:
- is available in their repositories on a supported release
- is internet facing
- is vulnerable to remote exploitation
- scores 7.5 “High” on the NVD severity scale
then make a decision to withhold the patch from their users who might reasonably expect that 5 years of support means 5 years of support. I think this confusion comes from Canonical’s decision to bundle the old “ESM” extended duration of support with the new “Ubuntu Pro” package which adds extended breadth of support. The hard-nosed, commercial, business-first decision is that users on standard LTS will be left vulnerable, even though a patch is tested and commercially available.
So why does the older 20.04 release get a free patch? Well, the particular version of Tomcat in 20.04 is directly inherited from Debian, who have patched and released it to their users. As part of “Best Effort”, Canonical pass on inherited security fixes for packages in universe.
As I’m running Tomcat on 22.04, what are my options?
- I could take an Ubuntu Pro subscription and access the patched version. Canonical offer 5 “free” subscriptions to non-commercial users. Sadly, these subscriptions get used up very quickly when running services in lxd containers. It may seem churlish, but as a hobbyist I’m not going to purchase extra subscriptions for all of my containers.
- Downgrade to 20.04 to access a patched version or upgrade to 24.04 to get a non-vulnerable version. Only the latter is feasible (the Ubuntu release manager doesn’t support downgrading to older releases), but it is quite a chore to change a whole operating system for the sake of one package. I think this is the route I’ll take but it will make me grumpy and I’ll always be worried that there will be a future vulnerable package which will fall out of the scope of LTS coverage.
- Change operating system entirely. Maybe it is time to go back to Debian, as they seem to release these fixes to their users?
Canonical have every right to aim to make a profit, and put food on the tables of their developers and engineers. Ubuntu Pro is a hugely impressive product; supporting tens of thousands of packages for a decade is a major feat. But, as a user, the messaging becomes very messy when “support” might not mean “support”.
You can send me feedback on Bluesky.
Addendum 🔗
This post briefly made it onto the front page of hackernews. Fortunately my little server didn’t melt. User markshuttle (I’m guessing that is sabdfl but don’t want to make assumptions) wrote:
This is intriguing. I’ve run pro attach in containers before, and they’ve counted against my allocation of machines on the Ubuntu Pro website. So I ran up a few test containers under my pro-attached 24.04 host and tried to attach them:
