Joomla TUF sprint june 2022 - Keeping the trojan horse outside of Joomla’s walls
Have you ever heard the story of the ancient city Troy? It had massive walls, keeping attackers outside and the city safe. However, the greek army, attacking the city, had a genius idea: they pretended to stop their attack and travel back home, while leaving a gift for the people of Troy: a huge wooden horse. The people of Troy were thankful for that gift and pulled the horse inside the city's walls - not knowing that greek soldiers have hidden themselves in the horse, crawling out at night, opening the doors for the rest of their army and thereby dooming the city.
What the greek soldiers didn’t know: they had just invited a so called “supply chain” attack - an attack type that’s still relevant for modern day IT. The basic idea is simple: you attack an IT system by compromising installation- or update packages. Once these packages are downloaded and installed, the attack code is executed and the system is compromised.
In order to prevent such an attack in the Joomla ecosystem, our update server manifest supports not only the links to the actual files, but also the possibility to provide cryptographic hashes, proving that the file content is correct - however, how can we be sure that those hashes aren’t compromised too? How can we be sure that both, information about an update and the actual update file itself are legitimate files and published by the actual developer?
Introducing “The Update Framework”
This is where “The Update Framework”, or just TUF comes into play. At it’s core, it’s a specification for an software-update distribution system that allows secure updates without supply chain attack vectors. It’s a great design and a perfect fit for the Joomla community, that’s why a small team started to implemented TUF for the Joomla core during the CloudFest hackathon in April 22.
The June sprint
To continue that project, a follow up sprint took place in Nuremberg, Germany, in June 2022. A group of 9 people worked on the three main elements that are required for TUF in the CMS:
- we need a server side infrastructure where the actual information about available updates can be retrieved from - but it’s primarily only a question of hosting a bunch of files, but how we want to setup our TUF
- repository for the core, what toolset is required to manage that repo and how a potential integration of 3rd party extensions could work
- we need to adapt the existing TUF client for PHP to be generic enough to not only fit the needs of Drupal, where the TUF client was initially developed, but also the needs of the rest of the PHP community
- we need to rework the existing update processes in the CMS to use that client to retrieve, verify and store update information and of course also apply the actual update
During the sprint, very good progress has been made in all three areas:
Server side infrastructure
Harald continued the work on the docker-based toolchain that was developed during CloudFest hackathon. He updated the underlying TUF implementation (which is written in Go) and implemented the necessary commands that we need for the keymanagement- and release-processes that require signatures from multiple persons.
A total of five pull requests to the upstream TUF client repo have been created, making the TUF client more generically usable by removing hardcoded dependencies and making the client more compatible with the TUF implementation that we are using for our serverside setup.
Integration into Joomla
The work done during the hackathon has been continued by adding a JHttp driver for the TUF client class. With that driver, the current codebase is now able to successfully fetch, verify and store update information retrieved from the TUF repository that the server team set up for the sprint. We also started adjusting the codebase of com_joomlaupdate to the new update information source.
Going down to rabbit hole - in the next sprint
Throughout the work that has been done during the sprint, it became more and more apparent to us that a TUF implementation for the core must be built with the extension ecosystem in mind in order to also allow 3rd party devs to switch to the TUF-based update approach. However, what sounds easy in the first place is actually a non-trivial problem to solve: should extension developers run their own repo? If so, how can the public keys of that developers be fetched initially? Is it realistic that developers run their own TUF repo, requiring a deep understanding of the concepts? And if developers don’t run their own repo, how can we build a “global” extension update repo that’s scalable and maintainable for both us and the 3rd party developers?
We haven’t made that decision yet, as a bunch of research and testing is required to provide us answers to the questions mentioned above. That’s why the team decided to do a follow up sprint to do the final architectural decisions and finalize the codebase based upon that.
Honour to whom honour is due
Last but not least I want to thank Franciska, Niels, Stefan, Tobias, Magnus, Benjamin, Timo and Harald for their contributions during the sprint! You people rock :) and of course I would like to specially thank Stefan for being such a great host and providing a productive and fun environment to work in.