PHPMailer Exploit – Remote Code Execution • Hacker News Board

Re: PHPMailer Exploit – Remote Code Execution

#21

Post by jpalomaki » Wed, Dec 28, 2016, 9:46 AM UTC

kogepathic wrote: post #4

Out of curiosity, why is PHPMailer invoking the command line at all? It would seem much safer to establish a TCP connection to the local MTA over port 25 or 587 and send the message that way. Admins can just use iptables to restrict access to the port to localhost, and/or do the same in their MTA config.

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...

Re: PHPMailer Exploit – Remote Code Execution

#22

Post by jackweirdy » Wed, Dec 28, 2016, 9:52 AM UTC

danieltillett wrote: post #20

thaumaturgy wrote: post #8

Earlier quoted context omitted.

Misguided developers incorrectly "validating" email addresses is the reason that one of my clients couldn't use one of the newer TLDs, ".place", and ended up scrapping it and trying to find something they wanted a lot less in the much more crowded .com space. It's also why I far-too-often run into forms that won't let me use a "+" in the username part of my email address, which I use to track who's responsible for se…

Sometimes not allowing a "+" is an anti-abuse feature. If you have a service tied to a customer providing a unique email address then you don't want them able to use a "+".

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.

Re: PHPMailer Exploit – Remote Code Execution

#23

Post by Synchro » Wed, Dec 28, 2016, 9:58 AM UTC

annnnd wrote: post #6

TL;DR: PHPmailer fails to properly sanitize input. When configured to use CLI sendmail, this can lead to arbitrary command execution. But then again, why would you send e-mail to just any address someone enters, without validating it for correctness? I know it is tough to validate all addresses according to RFC, but I'd rather block some legitimate users (which btw. probably know more about RFC than me and I'm sure c…

This is incorrect. Input sanitisation is not the problem here - PHPMailer sanitises and validates email addresses well enough. The problem is that a valid, sanitised email address can also be an attack in an inappropriate shell context. Much as an SQL injection attack string may be harmless in a shell context but lethal in SQL. Also the vuln does not apply to CLI sendmail, only when sending via the PHP mail() function, and it's at least partly due to bugs in PHP itself.

Re: PHPMailer Exploit – Remote Code Execution

#24

Post by Synchro » Wed, Dec 28, 2016, 10:06 AM UTC

Piskvorrr wrote: post #16

shimon_e wrote: post #2

It's not been patched yet. Edit: Seems like another exploit found 8 hours ago: https://github.com/PHPMailer/PHPMailer/issues/924 Probably wise to disable phpmailer on your servers for now.

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.

Re: PHPMailer Exploit – Remote Code Execution

#25

Post by danieltillett » Wed, Dec 28, 2016, 10:12 AM UTC

jackweirdy wrote: post #22

danieltillett wrote: post #20

Earlier quoted context omitted.

Sometimes not allowing a "+" is an anti-abuse feature. If you have a service tied to a customer providing a unique email address then you don't want them able to use a "+".

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.

Re: PHPMailer Exploit – Remote Code Execution

#26

Post by annnnd » Wed, Dec 28, 2016, 10:24 AM UTC

Synchro wrote: post #23

annnnd wrote: post #6

TL;DR: PHPmailer fails to properly sanitize input. When configured to use CLI sendmail, this can lead to arbitrary command execution. But then again, why would you send e-mail to just any address someone enters, without validating it for correctness? I know it is tough to validate all addresses according to RFC, but I'd rather block some legitimate users (which btw. probably know more about RFC than me and I'm sure c…

This is incorrect. Input sanitisation is not the problem here - PHPMailer sanitises and validates email addresses well enough. The problem is that a valid, sanitised email address can also be an attack in an inappropriate shell context . Much as an SQL injection attack string may be harmless in a shell context but lethal in SQL. Also the vuln does not apply to CLI sendmail, only when sending via the PHP mail() functi…

I am not blaming lack of input sanitization, the bug is clearly still there. What I am saying is that input sanitization would prevent this attack because it will only allow valid characters to get to your mailer, which will exclude spaces, tabs, double and single quotes. Thus I fail to see an exploit vector which would bypass proper input sanitization. Do you see it?

In general I agree that PHP mail() function should take a part of blame here for not exposing a sane interface. Spammers have abused many bugs where programmers failed to sanitize "To:" or "From:" addresses and attackers could pass \r and \n characters (which allowed adding BCC fields, effectively sending e-mails to arbitrary addresses).

> Also the vuln does not apply to CLI sendmail...

Sure it does: >> ...will result in the followig list of arguments passed to sendmail program:

EDIT: you probably meant to say that the vulnerability is only triggered when CLI sendmail is called via mail(), which is true. Configuring PHPMail to use sendmail via CLI directly apparently doesn't expose this vulnerability.

Re: PHPMailer Exploit – Remote Code Execution

#27

Post by Roritharr » Wed, Dec 28, 2016, 10:28 AM UTC

Synchro wrote: post #24

Piskvorrr wrote: post #16

Earlier 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.

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?

Re: PHPMailer Exploit – Remote Code Execution

#28

Post by annnnd » Wed, Dec 28, 2016, 10:30 AM UTC

thaumaturgy wrote: post #8

annnnd wrote: post #6

TL;DR: PHPmailer fails to properly sanitize input. When configured to use CLI sendmail, this can lead to arbitrary command execution. But then again, why would you send e-mail to just any address someone enters, without validating it for correctness? I know it is tough to validate all addresses according to RFC, but I'd rather block some legitimate users (which btw. probably know more about RFC than me and I'm sure c…

Misguided developers incorrectly "validating" email addresses is the reason that one of my clients couldn't use one of the newer TLDs, ".place", and ended up scrapping it and trying to find something they wanted a lot less in the much more crowded .com space. It's also why I far-too-often run into forms that won't let me use a "+" in the username part of my email address, which I use to track who's responsible for se…

Genuinly curious: does '+' trick work? I would imagine any infringing parties would learn to remove plus sign and all after it before selling the database of addresses by now...

Other than that: true, I hate incorrect validation. But I hate sloppy security practices even more.

Re: PHPMailer Exploit – Remote Code Execution

#29

Post by annnnd » Wed, Dec 28, 2016, 10:34 AM UTC

DCoder wrote: post #9

annnnd wrote: post #6

TL;DR: PHPmailer fails to properly sanitize input. When configured to use CLI sendmail, this can lead to arbitrary command execution. But then again, why would you send e-mail to just any address someone enters, without validating it for correctness? I know it is tough to validate all addresses according to RFC, but I'd rather block some legitimate users (which btw. probably know more about RFC than me and I'm sure c…

> When configured to use CLI sendmail, That's not correct. PHPMailer can be configured to send mail through raw SMTP, by directly invoking sendmail, or by calling PHP's mail() function (which is itself a wrapper around sendmail). This vulnerability affects only the last mode, when PHP's mail() calls sendmail. If you have PHPMailer configured to call sendmail directly, this vulnerability does not apply.

I stand corrected, thank you for clarifying.

Re: PHPMailer Exploit – Remote Code Execution

#30

Post by jexyru » Wed, Dec 28, 2016, 10:41 AM UTC

This discussion is broken by design. Using user input from contact form as "From" address for emails, sent from your site, is the mistake of your application - you should use something like "noreply@yoursite.com", why you put user email there? In addition - most probably such emails will not pass spam filters.