Problem/Motivation
This issue has been discussed with the Drupal Security Team, and approved for handling in public as there is no direct vulnerability / exploit.
It's possible to abuse the config sync import functionality in order to upload malicious files.
In order to access the functionality, a user must have one or more restricted permissions.
At present \Drupal\config\Form\ConfigImportForm will extract the content of an uploaded tarball into the config_sync_directory without any filtering or sanitisation of file attributes.
This means it's possible to include e.g. malicious executable files in the tarball and these will be extracted to the sync directory.
A bad actor would then need a way of actually executing those malicious files, but getting them onto the webserver at a predictable location and with the executable bit in tact could be one step in a chained attack.
Note that it should not be possible to use e.g. directory traversal to extract a file outside the sync directory, but this depends on the implementation in the PEAR Archive_Tar library. There has been at least one relevant vulnerability in the library in the past (e.g. https://github.com/advisories/GHSA-p8q8-jfcv-g2h2 ).
Steps to reproduce
Use the tarball import functionality at /admin/config/development/configuration/full/import to upload a tarball with content other than valid .yml configuration exports.
For example, an executable shell script within the tarball will be extracted into the sync directory.
Proposed resolution
The tarball import should only extract what appear to be valid .yml config files.
It should also sanitise the permissions of imported files; for example ensuring that they are not executable.
Remaining tasks
MR / review / merge etc..
User interface changes
I don't think we need to present error messages when there are files in the tarball that will not be extracted, or permissions that will be sanitised?
Introduced terminology
n/a
API changes
n/a
Data model changes
n/a
Release notes snippet
I don't think this needs a release note, as there is no change to the legitimate functionality.