COmanage Developers List

[Benn Oshrin <>]

Mike was asking about PHPMailer specifically, but I don't think we use 
any of these?

Which isn't to say there won't be a CakePHP announcement shortly...

On 1/5/17 10:58 AM, Scott Koranda wrote:
> ----- Forwarded message from Warren Raquel 
> <>
>  -----
>
> Date: Wed, 4 Jan 2017 22:12:15 -0600
> From: Warren Raquel 
> <>
> To: 
> ,
>  CTSC Software Developers Announcement
>         List 
> <>
> Subject: [ctsc-announce-inf-l] Vulnerability in PHP Mail Libraries
>         (CVE-2016-10033)
> Organization: National Center for Supercomputing Applications
>
> Vulnerability in PHP Mail Libraries (PHPMailer, SwiftMailer, ZendMail)
>
> CI Operators and CI Developers:
>
> Summary
> PHPMailer, SwiftMailer, and ZendMail, popular PHP mail libraries used in
> many content management systems and web application frameworks, have a
> vulnerability that can allow remote code execution if an attacker can
> input a malicious email address in a web form. Improper input validation
> when email address variables are handed to the library can pass crafted
> commands to sendmail.
>
> Impact
> An unauthorized remote attacker could use this vulnerability to execute
> arbitrary code in the context of the web server.
>
> Technical Details
> The issue is that the three toolkits (correctly) follow the RFC 3696
> specifications of allowing email addresses with spaces when quoted, e.g.
> " this is valid"@host.com. However, when an attacker adds an escaped
> quote (\") to the address, the quoted portion of the email address is
> (incorrectly) broken out into extra parameters which get passed to the
> PHP mail() function in the "additional_parameters" argument, and
> eventually passed to sendmail.
>
> This involves web forms which allow the user to enter values for
> "From:", "Cc:", "Bcc:", "Reply-To:", etc., as those values must be
> passed in the "additional headers" field of the PHP mail() function,
> which requires pre-processing by any PHP script. The "To:", "Subject:",
> and "Message:" values have specific parameters in the PHP mail function,
> so those headers are not impacted by this vulnerability.
>
> In the examples provided in the advisories below, arguments are passed
> to sendmail that allow it to output the message body that is submitted
> to an arbitrary log file. This log file can be a php file and the
> message body can be php code. When placed in a web directory that file
> can be accessed and executed in the context of the web server.
>
> Affected Software
> PHPMailer < 5.2.20 (CVE-2016-10033)
> Zend Framework < 2.4.11 (CVE-2016-10034)
> zend-mail < 2.4.11
> zend-mail 2.7.0
> SwiftMailer < 5.4.5 (CVE-2016-10074)
> Drupal core is not affected but the optional Drupal PHPMailer module is
> affected.
> WordPress core is not vulnerable to current disclosures. The upcoming
> WordPress 4.7.1 release will include mitigations to protect from other
> potential vectors.
>
> Detection
> Examine any PHP web services that provide any kind of form input for
> email. These can be feedback forms, comment sections, etc. Any PHP web
> service that accepts an email address and/or sends emails should be
> examined.
>
> Recommendations
> We recommend updating your affected PHP mail libraries to their latest
> supported version as soon as possible and examining other PHP code that
> calls the PHP mail() function for safe handling of the
> "additional_parameters" argument. If this is not possible you should
> consider limiting access to PHP web forms that accept email addresses.
>
> References
> *
> https://legalhackers.com/advisories/PHPMailer-Exploit-Remote-Code-Exec-CVE-2016-10045-Vuln-Patch-Bypass.html
> *
> https://legalhackers.com/advisories/ZendFramework-Exploit-ZendMail-Remote-Code-Exec-CVE-2016-10034-Vuln.html
> *
> https://legalhackers.com/advisories/SwiftMailer-Exploit-Remote-Code-Exec-CVE-2016-10074-Vuln.html
> *
> https://threatpost.com/phpmailer-swiftmailer-updates-resolve-critical-remote-code-execution-vulnerabilities/122795/
> * WordPress: https://core.trac.wordpress.org/ticket/37210
> * Drupal: https://www.drupal.org/psa-2016-004
>
> How CTSC can help:
> The potential impact of any vulnerability, and therefore the appropriate
> response, depends in part on operational conditions that are unique to
> each cyberinfrastructure deployment. CTSC can not provide a
> one-size-fits-all severity rating and response recommendation for all
> NSF cyberinfrastructure. Please contact us (http://trustedci.org/help/)
> if you need assistance with assessing the potential impact of this
> vulnerability in your environment and/or you have additional information
> about this issue that should be shared with the community.
>
>
>
>
>
>
>
> ----- End forwarded message -----