Re:PHPMailer Exploit – Remote Code Execution
by Roritharr on Wednesday December 28, 2016 @05:28AM
(#13269668)
I wonder why they don't provide a mitigation. It shouldn't be impossible to release a simple sanitizeAgainstCVE_2016_10045($email) function as a mitigation that people could right now plop into their applications until phpmailer gets fixed... or is filter_var($email,FILTER_VALIDATE_EMAIL) good enough?
[ Parent
| on HN ]
Re:PHPMailer Exploit – Remote Code Execution
by Piskvorrr on Wednesday December 28, 2016 @06:50AM
(#13269934)
For benign e-mail addresses, it is Good Enough: accepts the unusual but valid info%[email protected], punycode (and various other things that people usually toss out with the infamous [a-z]{2,4}), yet throws out the abovementioned monstrosity, even though it technically follows the letter of the RFC.
As for "why no mitigation" - even though it abstracts the horror of mail(), a library is a power tool with sharp edges, not a nicely wrapped single-button selfie app. In other words, it already does validation; input sanitization is beyond its scope IMNSHO (this literally means that valid, insane e-mail addresses do exist), and adding that by default would nerf the library. (Also, php_filter is an extension and not installed by default)