CVE-2024-38276: CSRF durch falsch verwendetes confirm_sesskey() in Moodle
An mehreren Stellen hat Moodle das CSRF-Token zwar geprüft, das Ergebnis aber verworfen. Eine fremde Webseite konnte so Aktionen im Namen angemeldeter Nutzer auslösen.
1Zusammenfassung
- Advisory
- MSA-24-0024
- System
- Moodle
- Komponente
- Kurs-Download, LTI-Werkzeuge, MoodleNet-Import, Aufgabe (core_course, enrol_lti, tool_moodlenet, mod_assign)
- Fehlerklasse
- Cross-Site Request Forgery (CSRF)
- Schwere
- Serious
Moodle schützt zustandsändernde Aktionen mit einem Sitzungsschlüssel, dem sesskey. Für die Prüfung gibt es zwei Funktionen: require_sesskey() bricht bei einem fehlenden oder falschen Schlüssel ab, confirm_sesskey() gibt nur wahr oder falsch zurück und überlässt die Entscheidung dem Aufrufer.
An mehreren Stellen stand confirm_sesskey() allein in einer Zeile, ohne dass das Ergebnis ausgewertet wurde. Die Prüfung lief, hatte aber keine Folgen. Betroffen waren der Download von Kursinhalten, die Konfiguration von LTI-Werkzeugen, der Import aus MoodleNet und die Korrektur neu skalierter Bewertungen in der Aufgabe.
Gemeldet von Vincent Schneider über den Security-Prozess von Moodle, veröffentlicht als MSA-24-0024.
2Wer ist betroffen
Angemeldete Nutzer, die eine präparierte Seite aufrufen. Die Aktion läuft mit deren Rechten.
Für einen Angriff braucht es eine präparierte Webseite und eine Person, die sie aufruft, während sie in Moodle angemeldet ist. Ihr Browser schickt das Sitzungscookie mit, und Moodle hält die Anfrage für ihre eigene.
Was sich dabei auslösen lässt, hängt von den Rechten dieser Person in Moodle ab.
3Auswirkung
Je nach Stelle konnte eine fremde Seite einen Import aus MoodleNet in einen Kurs anstoßen, ein LTI-Werkzeug konfigurieren, einen Download von Kursinhalten starten oder die Bewertungen einer Aufgabe neu berechnen lassen.
4Behebung
- Betroffene Versionen
- 4.4.0, 4.3.0 bis 4.3.4, 4.2.0 bis 4.2.7, 4.1.10 und älter
- Behoben in
- 4.4.1, 4.3.5, 4.2.8, 4.1.11
- Veröffentlicht
- 19.06.2024
Wo vorher confirm_sesskey() folgenlos aufgerufen wurde, steht jetzt require_sesskey(), oder das Ergebnis wird ausgewertet. Fehlt ein gültiger Schlüssel, bricht Moodle die Aktion ab.
Wer eigene Plugins pflegt, sollte nach confirm_sesskey()-Aufrufen suchen, deren Rückgabewert niemand prüft. Beim Schreiben neuer Seiten entsteht derselbe Fehler leicht wieder.
Diese Fehlerklasse prüfen wir in jedem Projekt, das wir bauen oder auditieren. Für fremden Code als Sicherheitsaudit.
5 / Kontakt
Sollen wir Ihre Moodle-Plugins prüfen?
Beschreiben Sie Ihr Vorhaben in drei kurzen Schritten. Wir melden uns in der Regel innerhalb eines Werktags.