Problem/Motivation
The CAS bulk user creation form is accessible to users with the "administer users" permission, but it exposes all roles except anonymous and assigns the submitted roles directly to the created user accounts.
This does not match Drupal core's normal user account form behavior. Core allows users with "administer users" to create and manage accounts, but the role assignment checkboxes are only exposed to users with "administer permissions".
Impact: a user who can administer users, but who is not allowed to administer roles and permissions, can create a CAS-enabled account with a privileged role such as administrator.
Relevant implementation: the route cas.bulk_add_cas_users requires only "administer users". The BulkAddCasUsers form loads all user roles, removes only the anonymous role, exposes the rest as checkboxes, and passes submitted roles directly into CAS user registration.
This was first reported privately. The Drupal Security Team reviewed it and approved a public issue. See Background information below.
Steps to reproduce
- Enable the CAS module.
- Create or use a role that has the "administer users" permission, but does not have the "administer permissions" permission.
- Log in as a user with that role.
- Visit
/admin/people/createand confirm the normal core user creation form does not expose role assignment. - Visit
/admin/people/create/cas-bulk. - Enter one or more CAS usernames and an email domain.
- Select a privileged role, for example the "administrator" role on Standard and Umami installs, or any site-defined administrative role.
- Submit the form.
- Confirm that the created CAS user account has the selected role.
Proposed resolution
Require "administer permissions" to expose and process role assignment, as core does. The attached patch does this and covers both cases with tests.
Remaining tasks
- Review and commit to 3.x.
- Backport to 2.x, where the patch does not apply.
User interface changes
The "Role(s)" checkboxes on /admin/people/create/cas-bulk are no longer shown to users who do not have "administer permissions".
API changes
None.
Data model changes
None.
Background information
- Confidential private issue: https://git.drupalcode.org/security/185289-cas-security/-/work_items/1. Included for reference. Please do not report access denied there as an error.
- This is handled publicly because the form requires the "administer users" permission, which core marks
restrict access: true. Under the Security Team's policy, an issue that can only be exploited by users who already hold such a permission does not get a security advisory. The team reviewed it on that basis and approved a public issue. - Credit: reported by herved, fix by claudiucristea, reviewed by bkosborne, evaluated by greggles, drumm and Heine Deelstra.
Issue fork cas-3620142
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #4
herved commentedI filed an issue to fix the ci there #3620145: Fix CI pipeline, PHPStan errors and the ddev setup
Comment #5
claudiu.cristeaThis was already RTBCed in the security repo. The MR is exactly the same
Comment #7
claudiu.cristeaThank you