Skip to content

v5.0.3 — security release

Choose a tag to compare

@davidpesce davidpesce released this 20 Jul 22:48

v5.0.3 — security release

This is a security release. All sites should upgrade. There are no database
changes and no configuration is required after upgrading.

Security fixes

Failed-event report was readable without a capability. report.php gated
access inside a switch whose default branch performed no capability check,
so any authenticated user could read the failed-event log via
report.php?id=2&run=1, bypassing logstore/xapi:viewerrorlog. Unknown report
IDs are now rejected. The exposure was limited to operational metadata (event
names, error categories, timestamps) — no personal data and no ability to change
state.

TLS certificate verification is now enabled for the LRS connection. The
plugin previously sent statements with CURLOPT_SSL_VERIFYPEER disabled, so
anyone able to intercept traffic between Moodle and the LRS could read learner
data, capture the LRS username and password from the Basic auth header, and
tamper with the response. Verification is now on by default, including on
upgraded sites that have not yet visited the settings page.

Unescaped output in the admin reports. The LRS response body and, in the
historic report, the username were written into HTML table cells without
escaping. A malicious or compromised LRS could execute script in a manager's or
administrator's browser. Both are now escaped.

New settings

Two settings have been added under LRS Connection:

  • Verify the LRS TLS certificate — on by default. Leave it on.
  • Custom CA certificate bundle — the path to a PEM bundle. Use this when the
    LRS presents a certificate from a private or internal certificate authority.
    This is the preferred alternative to turning verification off, because the
    certificate is still checked.

If your LRS uses a private CA and you upgrade without setting one of these,
statements will fail to send and the failed-event report will show
cURL error: SSL certificate problem: .... Set the CA bundle path to resolve
it.

Turning verification off is supported but is a last resort. It disables both the
certificate and hostname checks, which is more permissive than the previous
behaviour, and it is reported as a warning in
Site administration → Reports → Security checks so it does not stay hidden.
The check reports "not applicable" while the xAPI logstore is disabled.

Other changes

  • logstore/xapi:manageerrors and logstore/xapi:managehistoric are now
    declared as write capabilities, which reflects that they authorise
    requeueing events. Existing role assignments and overrides are unaffected.
  • Removed cli/testdataseeder.php, a development-only fixture generator that
    shipped in the release and could not run (it referenced $CFG before loading
    config.php).
  • Removed src/loader/lrs.php, an unused duplicate of the active LRS loader.
  • Transport-level failures now report the underlying cURL error instead of
    storing an empty message in the failed-event log.
  • The failed-notification email template no longer uses unescaped output for
    event names and counts.

Upgrade notes

  • No database changes.
  • Sites whose LRS uses a valid publicly-trusted certificate need no action.
  • Sites whose LRS uses a private CA should set the CA certificate bundle path.
  • Moodle 4.3 – 5.1 remain supported.

Credits

Issues identified in an automated security review by
MDL Shield.