Root Cause Analysis
The vulnerability lies in Moodle's assignment module, where multiple functions responsible for handling assignment actions failed to properly enforce anonymity when blind marking was enabled. The root cause was the direct use of the userid parameter from URLs and requests, instead of using an anonymized blindid. This resulted in the user's real ID being exposed in URLs and server-side processes for actions like viewing, editing, removing, or grading submissions. The patches address this by modifying these functions to prioritize the blindid parameter when blind marking is active. The corrected logic first attempts to identify the user via blindid, and only falls back to using userid if blind marking is not in use or no blindid is provided. This ensures that user identities remain confidential during anonymous assignment workflows.
Vulnerable functions
assign_grading_table::col_statuspublic/mod/assign/gradingtable.php
The function `col_status` in the `assign_grading_table` class was creating a URL for an action menu that directly included the user's real ID (`$row->id`) as the `userid` parameter, even when blind marking was enabled. This exposed the user's identity in the URL, breaking the anonymity of the submission process.
assign::viewpublic/mod/assign/locallib.php
When handling the 'addattempt' action, the `view` function in the `assign` class directly called `process_add_attempt` with a `userid` taken from the request parameters. It did not check for or prioritize an anonymized `blindid`, leading to the processing of the real user ID in what should be an anonymous context.
assign::view_grant_extensionpublic/mod/assign/locallib.php
The function `view_grant_extension` in the `assign` class directly used user IDs from the 'selectedusers' or 'userid' request parameters without first attempting to resolve an anonymized `blindid`. This meant that actions related to granting extensions would use the real user ID, compromising anonymity.
assign::view_remove_submission_confirmpublic/mod/assign/locallib.php
The function `view_remove_submission_confirm` in the `assign` class fetched the `userid` directly from the URL parameters and used it to construct a confirmation URL. This exposed the real user ID in the URL for the submission removal confirmation page, violating the principles of blind marking.
assign::view_graderpublic/mod/assign/locallib.php
The `view_grader` function in the `assign` class would resolve a `blindid` to a `userid` without verifying if blind marking was actually enabled for the assignment. This could be exploited to de-anonymize users by passing a `blindid` to the grader view.
assign::view_edit_submission_pagepublic/mod/assign/locallib.php
The function `view_edit_submission_page` in the `assign` class used the `userid` from the request parameters without checking for an anonymized `blindid` first. This led to the real user ID being used to render the submission edit page, breaking anonymity.
assign::process_submit_other_for_gradingpublic/mod/assign/locallib.php
The function `process_submit_other_for_grading` in the `assign` class was vulnerable as it directly accepted a `userid` from the request parameters. In a blind marking scenario, it should have prioritized the `blindid` to maintain user anonymity during the submission process.
assign::process_remove_submissionpublic/mod/assign/locallib.php
The function `process_remove_submission` in the `assign` class required a `userid` from the request parameters to remove a submission. It did not handle the `blindid` parameter, forcing the use of the real user ID and thus exposing it during the submission removal process in an anonymous assignment.
assign::process_revert_to_draftpublic/mod/assign/locallib.php
The function `process_revert_to_draft` in the `assign` class required a `userid` from the request parameters. It failed to use the `blindid` for anonymous submissions, leading to the exposure of the student's real ID when their submission was reverted to a draft.
assign::process_lock_submissionpublic/mod/assign/locallib.php
The function `process_lock_submission` in the `assign` class was vulnerable because it directly used the `userid` from request parameters. In a blind marking context, this exposed the user's identity when a submission was locked.
assign::process_unlock_submissionpublic/mod/assign/locallib.php
The function `process_unlock_submission` in the `assign` class directly processed a `userid` from the request. It should have used the `blindid` to identify the user in an anonymous assignment, but instead used the real ID, compromising anonymity.
