In May 2024, a serious vulnerability was discovered in Moodle, the world's most popular open-source learning management system. Tracked as CVE-2024-43440, this flaw could let attackers exploit how Moodle restores backups of its "blocks." If a malicious backup file is uploaded and restored, it might cause Moodle to include unexpected local files—potentially exposing confidential data or even allowing further attacks.

Here, I’ll break down what CVE-2024-43440 is, show a code example of how the flaw can be abused, explain the possible impact, and guide you on mitigation. This is exclusive, plain-English coverage you won’t find elsewhere.

What is CVE-2024-43440?

This vulnerability is related to the way Moodle handles restoring block backups. Blocks in Moodle are those extra content panels (like calendars, forums, etc.) that you see on course pages. When users backup and later restore blocks, Moodle reads backup files—sometimes ZIP archives containing various resources.

The Issue:
A flaw in Moodle's backup restore code means that files from inside a specially-crafted backup can end up *including local files* from the web server, depending on file paths present in the backup. This kind of bug is known as *Local File Inclusion* (LFI).

References

- Moodle Security Advisories: CVE-2024-43440
- CVE Details Page
- GitHub Moodle Commit

Moodle admins

- Organizations allowing course/restoration uploads by less-trusted users

Any Moodle site where attackers can upload and restore their own backups

If an attacker can create a backup file (for example, of a block) and upload it to your Moodle server, the flaw lets them *reference arbitrary local files*, which Moodle may try to access. This opens the door to information leaks or even a server compromise.

A Simple Example

Let's say the attacker is allowed to create and restore a block. They might create a backup ZIP with a manifest like this inside:

<block>
  <file>
    <filename>config.php</filename>
    <filepath>/etc/passwd</filepath>
  </file>
</block>

Or pack a block backup and, by tampering with internal file references, point Moodle to open /etc/passwd instead of an expected data file.

When the restore process runs, Moodle’s vulnerable code might look like

// Hypothetical vulnerable code:
$file = get_backup_file_path($backupfile);  // comes from backup XML
$path = '/var/www/moodle/blocks/' . $file;
include($path);  // BAD: 'config.php' or absolute path can be attacker-controlled

If the backup XML or manifest allows absolute file paths (like /etc/passwd or /var/www/moodle/config.php), the attacker could inject those, and Moodle would try to open them.

Unzipping it.

3. Editing the manifest or XML file referencing the block’s resource to use ../../config.php or /etc/passwd.

Restoring it via Moodle.

If the patch is not applied, this can reveal the contents of those files, or worse—allow for remote code execution if the attacker can include a PHP file with code inside.

#### Example: Leaking /etc/passwd on Linux

<block>
  <file>
    <filename>passwd_dump</filename>
    <filepath>/etc/passwd</filepathath>
  </file>
</block>

If the vulnerable code includes this file blindly, an attacker might see the local password file appear in the course block.

How to Fix It

- Upgrade Moodle to the latest version (security updates here)

Here's a patched code example (pseudocode)

$file = basename(get_backup_file_path($backupfile)); // strips path
$allowed_dir = '/var/www/moodle/blocks/';
$path = $allowed_dir . $file;
if (strpos(realpath($path), $allowed_dir) === ) {
  include($path);
}

Conclusion

CVE-2024-43440 is critical for Moodle admins and hosts. If misused, it could let attackers peer into the very heart of your server or use your platform for even bigger attacks.

References

- Official Moodle Release Notes
- CVE-2024-43440 MITRE Record
- Moodle Patch Commit

Stay safe, patch early, and never restore backups from users you don’t absolutely trust!

Timeline

Published on: 11/07/2024 14:15:16 UTC
Last modified on: 11/08/2024 19:01:03 UTC