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

1–10 of 109 posts

Re: PHPMailer Exploit – Remote Code Execution

#3

Post by 0x0 »

The advisory says exploitation is not limited to just systems running the original Sendmail MTA, but Postfix' "sendmail" wrapper apparently ignores the "-X" parameter... so how can a Postfix-based system be exploited?

Re: PHPMailer Exploit – Remote Code Execution

#4

Post by kogepathic »

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.

Re: PHPMailer Exploit – Remote Code Execution

#5

Post by 0x0 »

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.

It's using PHP's builtin mail() function, which happens to be a wrapper around /usr/bin/sendmail, and one of the parameters it takes is used as an "additional command-line parameter to sendmail". In particular, the "-f" switch is used to set the SMTP envelope MAIL FROM address. Apparently PHP's mail() tries to do some automagic shell escaping on the argument but it's likely not good enough and it also creates a conflict when callers such as PHPMailer also try to escape the parameter.

Re: PHPMailer Exploit – Remote Code Execution

#6

Post by annnnd »

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 can find a "nicer" e-mail address if they want to) than let some attacker use some vulnerability like this. Always whitelist valid input, never (just) blacklist it.

Also, I am baffled that frameworks I encountered never demanded from developer to specify exactly what kind of input it expects via POST & co.. It is trivial to write a set of functions like this:

    function input_post_email($field_name, $default_value)
    function input_post_string($field_name, $validation_regex, $default_value)
    ...
The point here is that framework should DEMAND from developer to specify format of each and every input var it needs. It should be difficult to bypass these restrictions, to demotivate developers doing it.

This is a first thing I made in every PHP project I started. Combined with Content Security Policy and output filtering it's... well, better than most other solutions. :)

Re: PHPMailer Exploit – Remote Code Execution

#7

Post by systematical »

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 true, I couldn't figure out why this wasn't working, then realized I had to comment out this validation:

  filter_var($app->request()->post('email'), FILTER_VALIDATE_EMAIL)

Re: PHPMailer Exploit – Remote Code Execution

#8

Post by thaumaturgy »

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 sending my email account off to third parties (e.g., "rob+paypal@....").

Some kinds of email validation are better than others. Using regular expressions and strictly adhering to the RFC is the one that developers are usually talking about when they say not to do it. filter_var(..., FILTER_VALIDATE_EMAIL) is sort of okay, although there are lots of edge cases that it doesn't handle correctly.

Re: PHPMailer Exploit – Remote Code Execution

#9

Post by DCoder »

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.

Re: PHPMailer Exploit – Remote Code Execution

#10

Post by thaumaturgy »

0x0 wrote: post #3

The advisory says exploitation is not limited to just systems running the original Sendmail MTA, but Postfix' "sendmail" wrapper apparently ignores the "-X" parameter... so how can a Postfix-based system be exploited?

Yeah, looks like you're right, and although there might be some ways to abuse other Postfix command line options for some kind of mail abuse, I don't see that it offers any options that'll write a file to a specific location. If true, that's another big point in Postfix's favor.

On one of my web-facing servers running Postfix:

    root@:/home/rob# sendmail -X/home/rob/test.log
    sendmail: fatal: unsupported: -X/
Post reply on HN