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

71–80 of 109 posts

Re: PHPMailer Exploit – Remote Code Execution

#71

Post by pvg »

koheripbal wrote: post #54
dfc wrote: post #50

Earlier quoted context omitted.

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.

Looks like a bot to me. Literally only pastes links. I'd suspect that some of the websites it links to generate ad-rev, while the wikipedia and reddit links are there to obfuscate the purpose of the bot. It's simple logic. If you notice, both the Reddit and HN source have the same source url.

I'd suspect that some of the websites it links to generate ad-rev

Did you find any? The 'simple logic' has to follow from some sort of evidence.

Re: PHPMailer Exploit – Remote Code Execution

#72

Post by jstewartmobile »

skarap wrote: post #67
jstewartmobile wrote: post #58

Per the writeup, it looks like they were already escaping their arguments, but they didn't know PHP's built-in mail() function was already doing that: PHPMailer 5.2.17 sanitizes the $Sender variable by applying escapeshellarg() escaping before the value is passed to mail() function. It does not however take into account the clashing of the escapeshellarg() function with internal escaping with escapeshellcmd() perform…

> 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, it takes more time than your server-side web process is alloted for execution, leading to your script being force-terminated prior to completion.

[in reply to skarap] The action of mail() depends on the mail/sendmail settings in your php.ini, so the behavior could be blocking or non-blocking depending on which client is used and which parameters are passed.

Re: PHPMailer Exploit – Remote Code Execution

#73

Post by skarap »

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,…

The default configuration for PHP (and I guess the most frequently used one) is using sendmail command. That command does just one thing - enqueue the message on the local server. It doesn't handle the delivery of the email.

That is also the case when using the mail server at 127.0.0.1 port 25.

One could have configured a remote SMTP server with authentication and that would be slow and would be affected by network issues, but same would happen with a remote RabbitMQ server.

Re: PHPMailer Exploit – Remote Code Execution

#74

Post by jstewartmobile »

skarap wrote: post #73
jstewartmobile wrote: post #72

Earlier quoted context omitted.

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,…

The default configuration for PHP (and I guess the most frequently used one) is using sendmail command. That command does just one thing - enqueue the message on the local server. It doesn't handle the delivery of the email. That is also the case when using the mail server at 127.0.0.1 port 25. One could have configured a remote SMTP server with authentication and that would be slow and would be affected by network i…

On most shared hosts, it blocks. The action taken by mail() is dependent upon your php.ini settings.

Re: PHPMailer Exploit – Remote Code Execution

#75

Post by tyingq »

ec109685 wrote: post #38

Isn't this really a vulnerability of php's mail() function (or at least evidence of bad design). It shouldn't let itself call a shell command with arguments unescaped.

It appears that it does escape shell commands. The issue is that PHPMailer had already escaped them. The exploit is exploiting the "double escape".

The real issue to me is that unlike Perl and Python, PHP doesn't provide a way to spawn a process without invoking /bin/sh. If PHP had support for the various incantations of exec(), you could pass arguments without needing the shell.

Re: PHPMailer Exploit – Remote Code Execution

#76

Post by 79d697i6fdif »

randomdrake wrote: post #64
jstewartmobile wrote: post #58

Per the writeup, it looks like they were already escaping their arguments, but they didn't know PHP's built-in mail() function was already doing that: PHPMailer 5.2.17 sanitizes the $Sender variable by applying escapeshellarg() escaping before the value is passed to mail() function. It does not however take into account the clashing of the escapeshellarg() function with internal escaping with escapeshellcmd() perform…

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

Re: PHPMailer Exploit – Remote Code Execution

#78

Post by dfox »

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,…

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
    SMTP server: 250 Ok
    client: DATA ... .
    server does its checks on the contents of message (again, nothing meaningful for smarthos), reformats it, adds Received and such and writes it out into queue
    SMTP server: 250 Ok: queued
    server wakes up the process that handles delivery by IPC and gives it queue ID of just created message
    client probably disconnects now
    outgoing SMTP daemon starts connecting to somewhere

Re: PHPMailer Exploit – Remote Code Execution

#79

Post by jstewartmobile »

dfox wrote: post #78
jstewartmobile wrote: post #72

Earlier quoted context omitted.

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,…

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

Re: PHPMailer Exploit – Remote Code Execution

#80

Post by SnowingXIV »

jexyru wrote: post #30

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.

Right, whenever using mail() even without PHPMailer or anything for a basic form I've always thought it was best to set it to something like the following

  $headers = "From: noreply@yourwebsite.com\n";
If you want to be able to reply to the email you can still set it with something like

  $headers .= "Reply-To: $email_address";
Then in your content body you could also include your $email_address variable.
Post reply on HN