Contrib.social

Fix permissions around editing field metadata so untrusted users cannot add dangerous file extensions

Open on Drupal.org →
Created on 15 November 2024, 5 months ago

This issue was discussed by the Drupal Security Team, and their decision was that this can be solved in a public issue.

Problem/Motivation

If a user has permission to adjust the allowed file extensions that can be uploaded via a File field, Image field, etc. they can add "html" or "htm" to the list and thereby gain access to upload malware via XSS exploits or what have you.

Not just core is affected, also at least Webform and Media (see #36).

Steps to reproduce

1. Login as an user with the permission to administer fields on entities that he/she can create/edit.
2. Add a file upload field to such an entity.
3. Set HTML or HTM as allowed extension.
4. Save.
5. Add an entity and upload test.html.

test.html basically being a skeleton html file with

. Visit the file.

Proposed resolution

Because this problem affects contrib modules as well, provide a new 'administer file extensions' permission specific to expanding the file extension list that other modules can also use, and mark it "restrict access" => TRUE to caution site administrators away from giving it out willy-nilly. Write an upgrade path that automatically grants it to users with "administer site configuration" permissions so existing sites are not broken. How this plays out in various core versions:
  • Drupal 6 is not vulnerable, since "administer content types" is already defined as a restricted permission by core (ref: https://www.drupal.org/security-advisory-policy), and CCK module only acts on nodes. Additionally, in #42 @David_Rothstein checked the places that allow file extensions to be added via the admin UI (blogapi.module and upload.module) and both require "administer site configuration" which is also a trusted permission.
  • Drupal 7 is vulnerable to this issue (via the field UI - for example taxonomy fields can be adjusted with "administer taxonomy" permission, which is not restricted) but we're currently hoping to fix that by making the field UI only ever available to trusted users. This is happening in the public queue at https://www.drupal.org/node/611294
  • Drupal 8 is not affected, according to @larowlan in #23, because it defines granular 'administer {entity type} fields' permissions, one per entity type, and these are already marked "restrict access" => TRUE. There is discussion about backporting some of this solution to Drupal 7 in the public queue at https://www.drupal.org/node/611294#comment-9542671.

Remaining tasks

User interface changes

API changes

Data model changes

📌 Task
Status

Active

Version

7.0 ⚰️

Component

file system

Created by

🇪🇪Estonia ram4nd Tallinn

Live updates comments and jobs are added and updated live.
  • Security improvements

    It makes Drupal less vulnerable to abuse or misuse. Note, this is the preferred tag, though the Security tag has a large body of issues tagged to it. Do NOT publicly disclose security vulnerabilities; contact the security team instead. Anyone (whether security team or not) can apply this tag to security improvements that do not directly present a vulnerability e.g. hardening an API to add filtering to reduce a common mistake in contributed modules.

Sign in to follow issues

Merge Requests

Comments & Activities

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024