Over the Easter weekend, news spread among the open source community that XZ, a file archiving tool similar to Zip and common to many Linux distributions, had been compromised with backdoor code. Fortunately, the exploit was identified before it made it to any stable operating system release, so the nature of the compromise isn’t really important here.
What’s far more important is how this was able to happen.
A developer identified as “Jia Tan” began contributing to XZ in 2022. Alongside their code contributions they used social engineering to gain greater trust from the project’s lead maintainer, eventually becoming a “co-maintainer”. This position of trust allowed them to inject their malicious code, and apply further pressure on Linux distribution maintainers to include the latest version of XZ in their packages. Whether this was an individual or a team, their combination of technical and social manipulation shows this was a deliberate and calculated attack, whose target will likely never be fully known.
That this was discovered in time was a lucky escape, and a reminder that the ability of anyone to inspect open source software is a powerful foil for malicious actors.
Even so, Catalyst’s clients would be remiss if this didn’t beg the question – could this happen to me?
In the case of the core Moodle LMS product, the happy answer is that it would be extremely difficult. As discussed in our previous article, How does open source-software stay secure, Moodle has a rigorous code review process by the community and by a team of paid maintainers. Even trusted members of the community who have been contributing for years have their contributions subjected to the same level of rigour. The chance of a malicious developer using social pressure to circumvent this process is very low.
One area that should create pause for thought is third-party plugins. The Moodle Plugins database contains over 2000 plugins, including many that haven’t been updated in several years. It’s conceivable that a malicious party could pressure a maintainer of a popular plugin who is no longer able to work on it to hand maintainership over to them. They could then follow a similar path to the XZ exploit, releasing a compromised version and encouraging users to update.
When adding plugins to your Moodle site, it is important to perform due diligence and ensure that the plugin is being well-maintained. A well-maintained plugin will have regular updates from a variety of developers, meaning the pressure isn’t piled on one individual. Bug reports will be responded to, and Pull Requests will be merged or rejected. If a project has financial sponsorship or commercial backing, the developers can dedicate more of their time to it. In the Moodle community, you can often meet developers at in-person MoodleMoots or online events, so you may be able to associate on-screen names with real individuals.
With a site that uses plugins, you should also perform regular reviews to ensure the due diligence you performed at the start still holds up. Does the plugin have a release for the current Moodle version? Is it still actively maintained? Has it changed hands since you first installed it?
Catalyst can help with all of this. We offer a comprehensive plugin review service which will assess the quality and security of the code itself, but also the health and sustainability of the project that produces it.
During upgrades, we can help review your plugins and remove any that have become obsolete or aren’t well maintained. If an unmaintained plugin is crucial to your organisation, the open source nature of Moodle’s ecosystem allows Catalyst to take over maintenance on your behalf, ensuring you stay secure into the future.
To learn more about how Catalyst keeps your Moodle secure email us or speak to your Account Champion.
