1. Who is affected?
2. What should I do to secure my application
3. What is the root of these vulnerabilities

Recently three security vulnerabilities in PHPMailer and SwiftMailer have been announced:

• 25.12.2016, CVE-2016-10033 Remote Code Execution vulnerability in PHPMailer
• 27.12.2016, CVE-2016-10045 Remote Code Execution vulnerability in PHPMailer
• 28.12.2016, CVE-2016-10074 Remote Code Execution vulnerability in SwiftMailer

Credits to Dawid Golunski (https://legalhackers.com) for finding these.

All three mention Yii among the affected frameworks in the initial release, so we want to comment on this to clarify who is affected and what action is required.

About PHPMailer, Yii has never officially provided any mailing component related to PHPMailer, nor do we bundle PHPMailer in any code released officially by the Yii team. The mentioning of Yii in the report was a copy and paste from the PHPMailer README, which claims that you can use it with Yii. In a later revision of the report, Yii is not mentioned anymore. As patches are available, the required action is to simply upgrade PHPMailer to at least version 5.2.20, if you use it.

The situation is different with SwiftMailer for which we provide a Yii2 extension: yii2-swiftmailer. The details are described in the following.

Update (29.12.2016): SwiftMailer has released version 5.4.5, which fixes the issue. Also the affected Swift_MailTransport class has been deprectated and will be removed in SwiftMailer version 6.0.

For feedback on this, you can use the related forum post.

Who is affected? ¶

Only users who use the Swift_MailTransport or PHPMailer classes for the mail transport, which uses the PHP mail() function. This however is the default transport and also the default used by the SwiftMailer extension. Also malicious code can only be injected if an attacker can set the Sender/From part of the email.

What should I do to secure my application ¶

Considering that the vulnerabilities are related to the From part of the email, this is the main area where you should check in all your applications. Try to remember, where users are allowed to set the sender email address. This is often the case in contact forms and Guestbook scripts.

When correctly validating user input, which you should be doing anyway, your app may not be affected at all.

It is a good practice to incorporate security directly in the area of the user input, before the data is handled and processed in other areas of the application (which could be third party software). Applications that have proper validation on email addresses entered by user input are less likely to be exposed to the mentioned vulnerabilities.

There are several solutions for securing your application.

• Yii's EmailValidator: To our knowledge, email addresses that are suitable for this kind of attack are rejected by the email validator.
• PHP's native filter_var() function: This function is specifically designed for email addresses validating. For example:

public function validateEmail() {
    if (filter_var($this->email, FILTER_VALIDATE_EMAIL) === false) {
        $this->addError($this, 'email' , 'This email contains characters that are not allowed');
    }
}

What is the root of these vulnerabilities ¶

Since PHP function mail() does not provide a separate argument to specify the sender email address, there is only one way to do it: pass a string to the $additional_parameters argument of the function, with a -f flag, followed by the email address (e.g. -fadmin@example.com). This will result in /usr/sbin/sendmail execution with a list of parameters passed to the mail() PHP function. For example:

/usr/sbin/sendmail -t -i -fadmin@example.com

In the case we pass email to the 3-rd argument manually, we recognize that it's a CLI argument and it should be properly validated and escaped. However, both PHPMailer and SwiftMailer provide a convenient API that hides this fact from the developer.

The discovered vulverabilities prove that the third parameter is not escaped reliably and the attacker can break out of it with some extra escaping. This means, that if the sender email address will be prepared in a special manner, it becomes a part of executed sendmail command.

For example, passing the following string as the 3-rd argument will result in injecting additional parameters -oQ and -X, that will access the server's file system and lead to data leakage:

-f"attacker\" -oQ/tmp/ -X/var/www/cache/phpcode.php  some"@email.com

// Results in call
/usr/sbin/sendmail -t -i -f"attacker" -oQ/tmp/ -X/var/www/cache/phpcode.php  some@email.com

Please, refer to the security vulnerabilities reports at the beginning of this article to learn more about the attack details.