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
Show commands
changes
Comments
Comment #2
ram4nd commentedComment #3
ram4nd commentedComment #5
ram4nd commentedComment #6
poker10 commentedI reviewed the issue and it seems like that the new permission proposed in the s.d.o. patch (and the MR) is not required anymore, as we already have "administer fields" permission in D7, starting from 2016 (see here: #611294: Refine permissions for Field UI). This permission is restricted (https://api.drupal.org/api/drupal/modules%21field%21field.module/functio...). The permission is used to protect fields UI, so it means that only trusted users can currently adjust allowed extensions on a specific field.
The second part of the MR (where .html and .htm) are added to the
FILE_INSECURE_EXTENSIONSis a hardening, but I do not think we can do such change in this D7 phase. Adding this would affect all sites and disable uploads of html files, unless sites allow all insecure extensions using theallow_insecure_uploadsconfiguration option. I think that would be a big change for existing sites. Also html and htm extensions are not marked as insecure in Drupal 8+ (see: https://git.drupalcode.org/project/drupal/-/blob/11.x/core/lib/Drupal/Co...).If all my findings are correct, I propose to close this as Won't fix. Or we can keep this issue for Drupal 10/11 to consider adding .html and .htm to
INSECURE_EXTENSIONS. Any thoughts? Thanks!