I wonder if WordPress SMTP plugins¹ that override normal mail functions provide any protection from this vulnerability.
[1]: Such as https://wordpress.org/plugins/wp-mail-smtp/
PHPMailer Exploit – Remote Code Execution
41–50 of 109 posts
Re: PHPMailer Exploit – Remote Code Execution
#42Earlier quoted context omitted.
That doesn't help - user input is already validated by default in PHPMailer - the problem is that a valid email address can also be an attack string in a shell context, and bugs in PHP make it hard to work around safely.
I wonder why they don't provide a mitigation. It shouldn't be impossible to release a simple sanitizeAgainstCVE_2016_10045($email) function as a mitigation that people could right now plop into their applications until phpmailer gets fixed... or is filter_var($email,FILTER_VALIDATE_EMAIL) good enough?
For benign e-mail addresses, it is Good Enough: accepts the unusual but valid info%blah+something@info.swiss, punycode (and various other things that people usually toss out with the infamous [a-z]{2,4}), yet throws out the abovementioned monstrosity, even though it technically follows the letter of the RFC.
As for "why no mitigation" - even though it abstracts the horror of mail(), a library is a power tool with sharp edges, not a nicely wrapped single-button selfie app. In other words, it already does validation; input sanitization is beyond its scope IMNSHO (this literally means that valid, insane e-mail addresses do exist), and adding that by default would nerf the library. (Also, php_filter is an extension and not installed by default)
Re: PHPMailer Exploit – Remote Code Execution
#43Earlier quoted context omitted.
Or, y'know, treat user input as untrusted. Radical, I know. And all the wooooork this would be to implement! Calling filter_var($sender, FILTER_EMAIL). Nah. Better throw it out completely and use mail() directly, that would be way safer. #sarcasm
That doesn't help - user input is already validated by default in PHPMailer - the problem is that a valid email address can also be an attack string in a shell context, and bugs in PHP make it hard to work around safely.
That's actually a part of the problem: "don't worry, the library covers you, no need to think about it". I have spent some time rooting around inside the libraries I planned to use - including PHPMailer - to find out what their assumptions are: "validates by default" is not a sufficient description (as we see), "passes everything conformant to RFC" is.
In this case, that was not the same assumption I was making, and I was surprised - once, during implementation; a wrapper using filter_var brought the assumptions of the library in line with the assumptions for the project. That is, obviously, not universal advice.
Re: PHPMailer Exploit – Remote Code Execution
#44Re: PHPMailer Exploit – Remote Code Execution
#45Earlier quoted context omitted.
>I know it is tough to validate all addresses according to RFC Understatement of the year! If you were to try and actually validate according to the RFC, chances are you'll introduce new vectors of attack in your code simply because of the complexity of what you're trying to achieve. Honestly, the email address RFC is a litany of insane choices and kludged-together standards to account for the wild west free-for-all…
That's how I do it. Check for an @. Anything past that is sendmail's problem.
Even though it false positives some valid emails, I've always felt requiring a @ and a . is a good check for public facing validation.
Re: PHPMailer Exploit – Remote Code Execution
#46Earlier quoted context omitted.
That seems like a strange place to verify that a user is only allowed to create one account. After all, they could just create a second email account on a free email provider and use that to sign up. To get around that, the service provider would have to verify identity further down the line, making the email format restriction redundant.
I have been down this route and you also have to disable the use of free email accounts. If the service value is not too high then even making people who want to abuse the service go through the process of registering a free email account works. Put a little bit of friction into the process and the script kiddies move onto an easier target.
> I have been down this route and you also have to disable the use of free email accounts.
I don't have any other email. Seems like a really bad idea.
Re: PHPMailer Exploit – Remote Code Execution
#47Earlier quoted context omitted.
Using command line is the standard way in Linux and de-facto standard in *nix world. "To deliver electronic mail (email), applications shall support the interface provided by sendmail (described here). This interface shall be the default delivery method for applications." http://refspecs.linux-foundation.org/LSB_3.0.0/LSB-PDA/LSB-P...
Yes but PHP runs on non-*NIX platforms[0]. So why not use an interface which is (a) more secure, and (b) platform independent? [0] http://windows.php.net/
[deleted]
Re: PHPMailer Exploit – Remote Code Execution
#48PHPMailer is also used by wordpress: https://www.wordfence.com/blog/2016/12/phpmailer-vulnerabili...
It's times like this I'm glad I have a country block setup through ipdeny. Reducing the likelihood of attack by two orders of magnitude is a big help until there's a patch.
Re: PHPMailer Exploit – Remote Code Execution
#49PHPMailer is also used by wordpress: https://www.wordfence.com/blog/2016/12/phpmailer-vulnerabili...
Looks like recent versions of WordPress may or may not reject emails with the quoted name format of "bad stuff"@example.com. Might depend on your plugins. My experimentation produced varied results for my sites and testbeds.
filter_var($email, FILTER_SANITIZE_EMAIL) works for this exploit, as it removes spaces and double quotes.
The SMTP plugins I surveyed still use PHPMailer.
You'd want to try something like:
/**
* Block the PHPMailer vulnerability:
* https://legalhackers.com/advisories/PHPMailer-Exploit-Remote-Code-Exec-CVE-2016-10045-Vuln-Patch-Bypass.html
*/
function example_wp_mail_filter($args) {
$new_wp_mail = array(
# Get rid of quotes in quoted emails: "bad stuff"@example.com. Should be
# sufficient sabotage.
'to' => preg_replace('[\'"]/u', "", $args['to']),
'subject' => $args['subject'],
'message' => $args['message'],
'headers' => $args['headers'],
'attachments' => $args['attachments'],
);
return $new_wp_mail;
}
add_filter('wp_mail', 'example_wp_mail_filter');Re: PHPMailer Exploit – Remote Code Execution
#50https://www.reddit.com/r/netsec/comments/5kot1a/phpmailer_52...
I am curious why you linked to reddit? There is nothing in the discussion (4 comments) that is not in the linked advisory.
Looking back through your comment history you seem to do this a lot, even linking to discussion pages on reddit with no comments whatsoever and the same link as found in the HN submission.