A Level-Headed Assessment Of CVE-2016-10033 And CVE-2016-10045

Published: December 28, 2016

Tags:

Titles like “Critical PHPMailer Flaw leaves Millions of Websites Vulnerable to Remote Exploit” or “PHPMailer Bug Leaves Millions of Websites Open to Attack” are great if you’re looking for clicks. However, when you take a closer look, you’ll see that these aren’t exactly accurate.

Blast radius of phpmailer was greatly hyped by bug author: requires app to use fairly sophisticated mail address validation (or none at all)

— Kenn White (@kennwhite) December 27, 2016

Here, I’ll take a level-headed look at recent vulnerabilities found in PHPMailer, CVE-2016-10033 and CVE-2016-10045.

Why All The Hubbub

The vulnerability has caused quite the stir because the rampant usage of the PHPMailer library.

The first line in the advisory for CVE-2016-10033 states…

PHPMailer continues to be the world’s most popular transport class, with an estimated 9 million users worldwide. Downloads continue at a significant pace daily.

Then it goes on…

Probably the world’s most popular code for sending email from PHP! Used by many open-source projects: WordPress, Drupal, 1CRM, SugarCRM, [..], Joomla! and many more

This background could be interpreted to mean that anyone running these platforms is currently vulnerable to this exploit.

Unfortunately, “anyone” is a bit of an overstatement.

What’s Required To Exploit It

The “About the CVE 2016 10033 and CVE 2016 10045 vulnerabilities” from the PHPMailer wiki lays out the requirements for for this vulnerability to be exploited. Essentially…

  1. First and foremost, user input must be used to generate the ‘From’ address when sending the email. This is sometimes done for convenience with contact forms as hitting “Reply” to the email that the form generates will direct the response to the individual who submitted the form. However it’s bad practice because the server that email is coming from (your server) most definitely isn’t authorized to send emails for e.g. @gmail.com or @msn.com, so it will fail checks such as DKIM or SPF. It is also worth noting that the $auto parameter in setFrom can be set to false which will allow the sender to be safely set from user input (but please don’t).
  2. PHPMailer needs to be delivering using the isMail() transport (which is the default). Delivery via SMTP is not vulnerable.
  3. All published PoCs will not work if your server is running Postfix because Postfix does not support the -X flag. That being said you can still inject other flags which attackers may find other ways to take advantage of.

Reviewing Implications on WordPress Sites

A lead WordPress developer has stated the following

Presently, WordPress Core (and as a result, anything utilising wp_mail()) are unaffected by the recent disclosures, the vulnerabilities require the usage of a PHPMailer feature which WordPress & wp_mail() does not use.

I haven’t played with it extensively, but from what I can see this change, which appears to have been introduced in WordPress 4.6, made usage of wp_mail safe, even when the “from” header is passed.

Older versions look like they may be vulnerable for forms configured to use user input to set the from address which looks to be a standard feature in contact form plugins.

Drupal & Others

Drupal has publicly stated there are no core vulnerabilities

Drupal core is not affected.

However, similar to WordPress, 3rd party modules are the concern.

Drupal installations are not vulnerable to the PHPMailer CVE-2016-10033 UNLESS they have a module that uses that 3rd party library.

— Drupal Security (@drupalsecurity) December 26, 2016

I haven’t looked at any of the other platforms at this point.

Bottom Line

The bottom line is that, while you should definitely upgrade PHPMailer as soon as possible (there will certainly be successful exploits on unpatched sites), some of the language being used to describe this vulnerability is a bit exaggerated.

If you have any questions or comments, feel free to drop a note below, or, as always, you can reach me on Twitter as well.

Hi, I'm Max!

I'm a software developer who mainly works in PHP, but also dabbles in Ruby and Go. Technical topics that interest me are monitoring, security and performance.

During the day I solve challenging technical problems at Something Digital where I mainly work with the Magento platform. I also blog about tech, work on open source and hunt for bugs.

I built a tool called Domain Clamp which monitors and alerts about expiring domains and SSL certificates.

If you'd like to get in touch with me the best way is on Twitter.