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

81–90 of 109 posts

Re: PHPMailer Exploit – Remote Code Execution

#81

Post by dfox »

jstewartmobile wrote: post #79
dfox wrote: post #78

Earlier quoted context omitted.

Both postfix and qmail are inherently incapable of blocking their clients on communication with destination/upstream smarthost because of their architecture. In both cases it works like this: client: MAIL FROM server checks whether it makes sense (outgoing smarthost has essentially nothing to check here) SMTP server: 250 Ok client: RCPT TO server checks, again there is nothing expensive to check for smarthost case SM…

exim and sendmail have synchronous options

I'm aware of that. My point is that when sending mail directly from web server process is too slow, correct solution is not building your own bug-ridden implementation of half of SMTP on top of some newfangled message queue, but simply configuring your outgoing mail server correctly.

When you only enqueue event such as "this happened, there should probably be an notification for that" and have some non-trivial application logic in the queue runner it starts to make sense. But queue runner of the kind for(;;) {msg = get_message(); smtp_send(message)} is complete nonsense.

By the way, I know of pretty significant line of bussiness system that has nothing to do with email except the fact that it uses smtp and postfix as it's message bus and the thing seems to just work without issue, for more than decade.

Re: PHPMailer Exploit – Remote Code Execution

#82

Post by arasx »

throwanem wrote: post #40
kogepathic wrote: post #36

Earlier quoted context omitted.

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/

Why do anything that makes sense? All I can say about the PHP maintainers' decision process without swearing is that it bewilders me. Last time I tried configuring a Linux-hosted PHP to do SMTP on localhost:25 instead of shelling out to call sendmail, I found that only Windows builds even have that functionality compiled in. You can apply the same configuration options on a stock Linux build, and they won't cause err…

There are hundreds of ready made libraries which help you easily talk to SMTP without invoking a shell cmd. You also have the option to use sock functions (fsockopen) and write your connection wrapper. These are not windows-only features.

Re: PHPMailer Exploit – Remote Code Execution

#83

Post by jstewartmobile »

dfox wrote: post #81
jstewartmobile wrote: post #79

Earlier quoted context omitted.

exim and sendmail have synchronous options

I'm aware of that. My point is that when sending mail directly from web server process is too slow, correct solution is not building your own bug-ridden implementation of half of SMTP on top of some newfangled message queue, but simply configuring your outgoing mail server correctly. When you only enqueue event such as "this happened, there should probably be an notification for that" and have some non-trivial applic…

Never said to re-implement SMTP. Just stating that I've been on shared servers where PHP mail() blocks and had to job-out SMTP for responsiveness. If I've encountered it, I'm sure others have as well.

As for the jobber, it was using the same PHP mail() function, it's just that the jobber runs async and does not have a time limit imposed on it.

If you have control over your php.ini to where you can set agent parameters to be non-blocking, then yes, that would be ideal.

Re: PHPMailer Exploit – Remote Code Execution

#84

Post by [deleted] »

jstewartmobile wrote: post #72
skarap wrote: post #67

Earlier quoted context omitted.

> In those cases, it really isn't a good idea to send mail in-process anyway due to web-process and SMTP timeouts Why is sending a message to something like RabbitMQ less likely to timeout then to postfix?

Job queue services have async modes where enqueueing the message returns immediately. Then the jobber can send the message under a more limited account, or even on a different machine in a different language without timeouts. Last I checked, PHP's mail() function blocks until SMTP connect/auth/submit completes, and with things like SMTP tarpitting, or just ordinary slowness, that can take a very long time. Sometimes,…

[deleted]

Re: PHPMailer Exploit – Remote Code Execution

#85

Post by throwanem »

arasx wrote: post #82
throwanem wrote: post #40

Earlier quoted context omitted.

Why do anything that makes sense? All I can say about the PHP maintainers' decision process without swearing is that it bewilders me. Last time I tried configuring a Linux-hosted PHP to do SMTP on localhost:25 instead of shelling out to call sendmail, I found that only Windows builds even have that functionality compiled in. You can apply the same configuration options on a stock Linux build, and they won't cause err…

There are hundreds of ready made libraries which help you easily talk to SMTP without invoking a shell cmd. You also have the option to use sock functions (fsockopen) and write your connection wrapper. These are not windows-only features.

Of course. The part I still can't get my head around is where the language feature that'd relieve me of the need to vet a library, or worse write socket code by hand like some kind of barbarian, isn't compiled in for non-Windows platforms, because reasons.

Re: PHPMailer Exploit – Remote Code Execution

#86

Post by hartz »

cdevs wrote: post #61

We're jerks and just strip everything down to a-Z space .- and @ _ anything beyond that f u, extensions and 3rd party library or even core filters come out with these vulnerabilities all the time, at least we will know for sure what characters were passed in from the start though I'm sure most business NEED to support every wacky combination but I'll take the complaint over the hack any day.

So you are one of those sites that reject email addresses with "+" in it?

Re: PHPMailer Exploit – Remote Code Execution

#87

Post by tyingq »

79d697i6fdif wrote: post #76
randomdrake wrote: post #64

Earlier quoted context omitted.

> It looks like better documentation could have prevented this bug. Where? Barring user-submitted comments, PHP has consistently had some of the most complete programming language documentation. This exact issue is specifically documented with the mail() function[1] so I'm not sure you can blame PHP or ask for better documentation in this case: "This parameter is escaped by escapeshellcmd() internally to prevent comm…

Why is it possible to do command execution in a mailer at all??? Any reasonable language would have abstracted this into an SMTP library where such things are impossible instead of relying on sendmail.

Likely because PHP has to run things while the end user is waiting for a page to download. They rely on sendmail so that the mail can be queued, versus hanging while the email is sent. PHPmailer can be configured in the way you're describing, but it then has this issue.

Re: PHPMailer Exploit – Remote Code Execution

#88

Post by ajsalminen »

tyingq wrote: post #55
Sanddancer wrote: post #13

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 ( stri…

As far as I can tell, PHP doesn't have any way to spawn a subprocess without passing it to /bin/sh for evaluation. PHPMailer (not core php) apparently either calls php's popen(), which passes to the shell...or calls php's mail(), which uses popen(). There are other options in php, like proc_open(), but they also call /bin/sh. TLDR: There isn't any way in PHP to avoid "relying on the shell to separate options for you"…

It's possible with pcntl_fork() and pcntl_exec() but that's not compatible with apache's mod_php which is probably still pretty widely used even though it's getting replaced by php-fpm.

Re: PHPMailer Exploit – Remote Code Execution

#90

Post by tyingq »

ajsalminen wrote: post #88
tyingq wrote: post #55

Earlier quoted context omitted.

As far as I can tell, PHP doesn't have any way to spawn a subprocess without passing it to /bin/sh for evaluation. PHPMailer (not core php) apparently either calls php's popen(), which passes to the shell...or calls php's mail(), which uses popen(). There are other options in php, like proc_open(), but they also call /bin/sh. TLDR: There isn't any way in PHP to avoid "relying on the shell to separate options for you"…

It's possible with pcntl_fork() and pcntl_exec() but that's not compatible with apache's mod_php which is probably still pretty widely used even though it's getting replaced by php-fpm.

I believe many distributions disable pcntl_* functions even in a php-fpm environment. You can make it work, of course, but it's not the default.
Post reply on HN