- Issue created by @dokumori
Drupal 8.x allows exporting the configuration as a tar archive (Manage,
Configuration, Configuration sync, Export). The responsible code resides in
"core/modules/config/src/Controller/ConfigController.php:downloadExport" and
uses the "ArchiveTar" class.
The configuration is exported to a temporary directory determined by
"core/lib/Drupal/Component/FileSystem/FileSystem.php:getOsTemporaryDirectory".
Often that's a system-wide temporary directory such as "/tmp".
Before the configuration is exported an attempt is made to delete an existing
archive. Unfortunately any and all errors are non-fatal and cause log messages
at best. That alone would allow an attacker with write access to the temporary
directory to insert a world-writable file which can't be removed by Drupal and
which would receive the exported configuration (prone to race conditions, of
course).
The ArchiveTar code in "core/lib/Drupal/Core/Archiver/ArchiveTar.php" detects
when compressed a file has a size larger than 0 bytes
("ArchiveTar:_openAppend"). In such cases it attempts to rename the file which
would fail if an attacker had it prepared. The workaround for an attacker is
to use a FIFO as the "filesize" function reports a size of 0 for those. What
can be read from the FIFO isn't directly usable as a tar archive due to
duplicate headers, but after decompression using "zcat" or similar a lot of
plain text configuration bits can be read.
The resource to trigger the configuration export,
"/admin/config/development/configuration/full/export-download", requires
authentication, but a GET request without CSRF token is sufficient to start the
export. As such an admin may be tricked into invoking that URL via an image
tag, for example.
Generally speaking programs should never re-open a temporary file after
deletion or renaming. If they must remove or rename a temporary file they
should do so only in a newly created temporary directory under their control
(mkdtemp(3), etc.).
- hansmi
- mlhess
Active
10.2 ✨
Last updated
It is used for security vulnerabilities which do not need a security advisory. For example, security issues in projects which do not have security advisory coverage, or forward-porting a change already disclosed in a security advisory. See Drupal’s security advisory policy for details. Be careful publicly disclosing security vulnerabilities! Use the “Report a security vulnerability” link in the project page’s sidebar. See how to report a security issue for details.