Moodle versions 3.10 to 3.10.1, 3.9 to 3.9.4, 3.8 to 3.8.7, and 3.5 to 3.5.16 suffer from cross site scripting and server-side request forgery vulnerabilities.
7471646474258c2352a99910d5c8889622-10-2021 - rekter0
Moodle is an opensource learning management system, popular in universities and workplaces largely used to manage courses, activities and learning content, with about 200 million users
Versions affected 3.10 to 3.10.1, 3.9 to 3.9.4, 3.8 to 3.8.7, 3.5 to 3.5.16
CVE identifier CVE-2021-20280
# Summary
When managing a course in Moodle, it's possible to add a 'Feedback' activity. This activity-type allows enrolled students to provide feedback to different questions created by the teacher. Some of these question types allow the students to provide text-input as feedback (eg. 'Short text answer'). The input provided has HTML striped before being inserted into the database and is supposedly sanitized in a safe way before being rendered, during this process, and for unkown reasons to me, moodle did html entities decoding leading to a stored XSS vulnerability and Blind SSRF.
# Vulnerability analysis
When a student submits their feedback text answer it is processed with s() function before being stored in the database
/mod/feedback/classes/completion.php
> $itemobj = feedback_get_item_class($item->typ);
> $newvalue['value'] = $itemobj->create_value($data->$keyname);
// Update or insert the value in the 'feedback_valuetmp' table.
if (array_key_exists($item->id, $existingvalues)) {
$newvalue['id'] = $existingvalues[$item->id];
$DB->update_record('feedback_valuetmp', $newvalue);
} else {
$DB->insert_record('feedback_valuetmp', $newvalue);
}
feedback_get_item_class loads class processor for that feedback input type
/mod/feedback/item/textfield/lib.php
public function create_value($value) {
> return s($value);
}
create_value() process input with s() function
/lib/weblib.php
/**
* Add quotes to HTML characters.
*
* Returns $var with HTML characters (like "<", ">", etc.) properly quoted.
* Related function {@link p()} simply prints the output of this function.
*
* @param string $var the string potentially containing HTML characters
* @return string
*/
function s($var) {
if ($var === false) {
return '0';
}
> return preg_replace('/&#(\d+|x[0-9a-f]+);/i', '&#$1;',
> htmlspecialchars($var, ENT_QUOTES | ENT_HTML401 | ENT_SUBSTITUTE));
}
As in function description, it removes tags and process the input with htmlspecialchars
Stored XSS
When rendering the answer entry, mid of the process, moodle used to do html_entity_decode
/mod/feedback/classes/response_table.php
public function other_cols($column, $row) {
if (preg_match('/^val(\d+)$/', $column, $matches)) {
$items = $this->feedbackstructure->get_items();
$itemobj = feedback_get_item_class($items[$matches[1]]->typ);
$printval = $itemobj->get_printval($items[$matches[1]], (object) ['value' => $row->$column]);
if ($this->is_downloading()) {
> $printval = html_entity_decode($printval, ENT_QUOTES);
}
return trim($printval);
}
return $row->$column;
}
So, if a user supplied a payload with hex-encoded values, e.g. '< ;' instead of '<' it would have remained the same after s() have had processed it. this would have gone under the radar of the sanitizer, and moodle would have decoded it during rendering process. The stored XSS could have been leveraged to trigger a blind SSRF.
# Impact
An authenticated attacker with the least privilege (student), could inject html/js with a crafted response to feedback activity leading to a stored XSS and blind SSRF. Successful exploitation of the XSS vulnerability allows the attacker to takeover moodle users including teachers and administrators or perform actions on their behalf. Exploiting the Blind SSRF would have given the attacker the ability to interact with internal server services and possible RCE in some environement setups.
# Timeline
12-01-2021 - Reported
01-02-2021 - Vendor confirmed
15-03-2021 - Fixed in new release