- Issue created by @AdamPS
- Status changed to Postponed
9 months ago 10:51am 10 October 2023
Follow on from 📌 Add symfony/mailer into core RTBC , which has the following section Security considerations
The mailer_dsn key in system.mail config stores the symfony mailer data source name. This is used to select the mailer transport. Examples of valid DSN include null://null, smtp://user:pass@smtp.example.com:25 or sendmail://default. Many DSN also take additional options in form of URL query parameters.
The sendmail transport optionally takes a command option used to specify the path to the sendmail binary. Accounts with write access to the mailer_dsn key in system.mail may use this option to execute any binary on the host accessible by the web server process.
===
Executing any binary allows reading of settings.php, of logs, and any file on the server with global read access (which is the default umask on Ubuntu). It likely allows direct modification of any part of the Drupal database. It reveals the existing users, running software, and open ports. It would likely give an attacker a lot of information to break into the machine. On a poorly configured server, there might be access to change various files.
We shouldn't allow all this even for a fully trusted admin user. It greatly increases the damage if that admin user's account should be hacked.
cat the settings.php file instead of sending the configured email, conditional on a specific `to` address.Restrict configuration of sendmail commands based on available options specified in settings.php. There is existing code to do this already in Drupal Symfony Mailer module.
First we would need to fix 📌 [PP-1] Add symfony mailer transports to DIC Postponed .
Postponed
11.0 🔥
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.