Moodle and Open Source Security

Feb 03, 2009

Miles Berry

There was a story in Friday’s TES{#u8_7} about a number of schools’ Moodle installations being compromised, resulting in some fairly graphic pornography ending up on these school’s learning platforms. Whilst I’m not sure of the exact details of this particular exploit, this could so easily have been avoided, in this case by just keeping the software up to date.

The security of open source applications is a complex but interesting area. Security is an issue which open source projects have to take seriously, for the sake of the project’s and the developers’ reputation if nothing else. Eric S Raymond’s seminal ‘The Cathedral and the Bazaar{#t7dp}‘, includes Linus’s Law{#hvjt}: that ‘given enough eyeballs, all bugs are shallow’, and thus, by exposing the source code to the scrutiny of large, technically literate user and developer communities, the chance of any security loop-hole being spotted is far greater than if access to the source code is limited to just the developer team itself. In the crucial area of cryptography, it’s been held since the 19th century that, in essence, the only secure algorithms are open algorithms (Kerchoff’s Principle{#k701}) – it’s easy enough to write an encryption routine that you yourself couldn’t break (I remember doing this myself at the age of 13), far harder to write one which will pass the scrutiny of a world-wide community of crypto experts.

The very openness of open source development means that as soon as the project community becomes aware of an exploit, the developer team swiftly springs into action to implement a patch, but more often the exploits are reported directly to the developers who will tend to fix this stuff in private, and then publish the update or patch. Better still, direct access to the developers without the need to go through ‘customer service’ and ‘technical support’ means that those who can fix these vulnerabilities get to them so much more quickly. It’s worth remembering that proprietary code is not without the occasional security problem: see recent news of security exploits in a certain proprietary browser{#plkg} and compare the number of viruses, trojans and spyware on a well know proprietary operating system with those on Linux.

Moodle, despite the TES’s reports, has a very good approach to security{#w6cl}. Whilst anyone can submit bug reports to Moodle’s bug tracker, Petr Škoda’s Moodle Security Team are the only ones who get to see those flagged as serious security issues, at least until they’ve been assessed. When admins set up their Moodle sites, they normally register the site with, and can sign up for security update emails in the process, alerting them to new code releases before they appear publicly, thus allowing them to keep their installations up to date before potential exploits are given publicity through release notes. The responsibility, of course, remains with those running the webhosting of a particular installation to ensure that the code underlying an instance of Moodle is up-to-date with the latest patches, but Moodle’s version control system (CVS) allows site administrators to update automatically on a daily basis to the latest stable release, complete with the latest bug fixes.

Keeping the Moodle code itself up to date is not enough if there are vulnerabilities with the underlying LAMP stack (Linux, Apache, MySQL, PHP). These projects have excellent security records too, but from time to time bugs are spotted, some of which might well have security implications. Modern Linux distributions make it very easy to keep the Linux kernel itself and all these other applications bang up to date: Ubuntu (and Debian’s) apt-get upgrade being just one of the ways of doing this.

Like their proprietary alternatives, Moodle and other open source web-based applications are complex creations, but the openness of the development process leads, on the whole, to quicker spotting of problems, and a fast response from the experts when problems are spotted. The very ease (and low cost!) with which these applications can be deployed means that they’re not always in the hands of professional system administrators, but then security notifications, CVS (etc) and package updates make it easy for even us amateurs to keep our systems up to date.