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.
> I have been down this route and you also have to disable the use of free email accounts. I don't have any other email. Seems like a really bad idea.
It depends on the service. Some services are only aimed at business which have their own domain, but yes I agree this is a pretty drastic step to take.
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…
Quite the contrary: most installs I've seen have a "remote" dedicated SMTP server which is actually on local network (not significantly slower than mail()), and does other useful stuff like DKIM and SPF (which, with appropriate setup, has the added bonus that rogue app-server emails don't just appear out of nowhere, and at the very minimum have to pass through this server, giving you a place to debug). Of course, if you're making My First Blog Server on a shared host, then all of this is moot.
PHPMailer is also used by wordpress: https://www.wordfence.com/blog/2016/12/phpmailer-vulnerabili...
Looks like recent versions of WordPress may or may not reject emails with the quoted name format of "bad stuff"@example.com. Might depend on your plugins. My experimentation produced varied results for my sites and testbeds. filter_var($email, FILTER_SANITIZE_EMAIL) works for this exploit, as it removes spaces and double quotes. The SMTP plugins I surveyed still use PHPMailer. You'd want to try something like: /** *…
Oh geez. That does block the exploit, but breaks the functionality. `"Random A. Person" `
(Also, if the SMTP plugin uses PhpMailer, but actually is configured to talk to SMTP, there is no mail() and the issue is moot)
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.
¯\_(ツ)_/¯ PHP. This is one of the insane decisions made in PHP4 that stays there because it's always been there.
I wonder if WordPress SMTP plugins¹ that override normal mail functions provide any protection from this vulnerability. [1]: Such as https://wordpress.org/plugins/wp-mail-smtp/
Yes. This is only exploitable if you're using `mail()` to invoke the local MTA; if you're talking to a SMTP host, this exploit has nothing to work with.
That's how I do it. Check for an @. Anything past that is sendmail's problem.
Even though it false positives some valid emails, I've always felt requiring a @ and a . is a good check for public facing validation.
Technically valid e-mail addresses - but nonsensical ones. I haven't seen an e-mail without a domain cross a network in decades ("cross a network" excepts "user@localhost", and I'm not old enough to have seen any IP-adressed mails ;)).
So yes, I believe that in 2016, a match on ^[^@]+@([^.@]+\.)+[^.@]+\.?$ does not have any actual false negatives, although allowing false positives. That's not entirely helpful in this CVE, though.
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.
someone123@example.com is not amused. Might as well say "we throw out every e-mail that contains the letter 'b', because Reasons. Makes us feel warm, fuzzy and secure."
I wonder if WordPress SMTP plugins¹ that override normal mail functions provide any protection from this vulnerability. [1]: Such as https://wordpress.org/plugins/wp-mail-smtp/
Yes. This is only exploitable if you're using `mail()` to invoke the local MTA; if you're talking to a SMTP host, this exploit has nothing to work with.