Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PHPMailer Exploit – Remote Code Execution

legalhackers.com

Post reply on HN
Print view View original

11–20 of 109 posts

Re: PHPMailer Exploit – Remote Code Execution

#11

Post by DCoder »

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.

PHPMailer can be configured to send mail through raw SMTP, by directly invoking sendmail, or by calling PHP's mail() function (which is a thin wrapper around sendmail). This vuln affects the last mode, where the command line is invoked by PHP itself. Yes, a good admin would configure mail differently, but this being PHP, it tries to be flexible and support the simplest options possible.

Re: PHPMailer Exploit – Remote Code Execution

#12

Post by janeandrews »

If you have infidelity issues like I had, I strongly suggest you hire a pro hacker with 100% success, he helped me out with several deals and I am sure he can help you out as well.He is truly a genius at what he does. It was worth the fee. You can reach him via his eMail: vietnamguru@programmer.net

Re: PHPMailer Exploit – Remote Code Execution

#13

Post by Sanddancer »

The root cause of this is that PHP's mail function is broken by design. Instead of parameterized values for everything, it passes the entirety of the "additional" options, which includes the from address, as one string for the shell to parse. If the flags were pulled out to individual options to be passed to the command instead, it wouldn't be possible to exploit things in the way it does. So, instead of:

    mail ( string $to , string $subject , string $message [, string $additional_headers [, string $additional_parameters ]] )
it would be something like:

    mail ( string $to , string $subject , string $message [string $additional_headers], [string $additional_parameter, string $parameter values ] )
With the result passed to sendmail via the underlying functions, not relying on the shell to separate options for you. Any sort of user-supplied data should be parameterized and treated differently than data you provide. We've mostly learned our lessons from SQL injection, the rest of the stack still has a problem.

Re: PHPMailer Exploit – Remote Code Execution

#14

Post by adjkant »

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…

I somehow went through life not knowing the + trick. Thanks, and commenting to hopefully highlight this for anyone else who didn't know.

Re: PHPMailer Exploit – Remote Code Execution

#16

Post by Piskvorrr »

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

Re: PHPMailer Exploit – Remote Code Execution

#17

Post by thaumaturgy »

adjkant wrote: post #14
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…

I somehow went through life not knowing the + trick. Thanks, and commenting to hopefully highlight this for anyone else who didn't know.

The specific character depends on your MTA configuration. In Postfix this is the recipient_delimiter setting. I went with a "+" because that's the same character Gmail uses. Other mail services may not support this feature. Hope this helps!

Re: PHPMailer Exploit – Remote Code Execution

#18

Post by neotek »

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…

>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 existed before the modern internet emerged, and most of it has no bearing on the reality of how people use and create email addresses today. Better to just check if the address supplied has an @ in it somewhere and be done with it.

Re: PHPMailer Exploit – Remote Code Execution

#20

Post by danieltillett »

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…

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 "+".
Post reply on HN