Should I be worried about the latest Zend-Mail RCE Vulnerability similar to the PHP-Mailer/Swift Mailer Vulnerability if I use Magento?

Question

From the recently disclosed Zend-mail remote code execution vulnerability:

Affected Zend Framework versions:

Zend Framework < 2.4.11 Remote Code Execution (CVE-2016-10034)

zend-mail < 2.4.11

zend-mail < 2.7.2

Should I be worried about this if Magento uses Zend Framework? Does Magento take proper precautions in sanitizing all types of email forms out-of-the-box?

Answer 1

Yes, you should be worried about this. Magento also published a post on their security center, describing a temporary workaround until they released a patch: https://magento.com/security/news/new-zend-framework-1-security-vulnerability

Answer 2

To your point about sanitization, the issue for most Magento shops would be introduced if control of the sender was given from a client-side form. Consider this core code:

class Mage_Core_Model_Email_Template ...

    public function send($email, $name = null, array $variables = array())
    {
        ...   
        $setReturnPath = Mage::getStoreConfig(self::XML_PATH_SENDING_SET_RETURN_PATH);
        switch ($setReturnPath) {
            case 1:
                $returnPathEmail = $this->getSenderEmail();
                break;
            case 2:
                $returnPathEmail = Mage::getStoreConfig(self::XML_PATH_SENDING_RETURN_PATH_EMAIL);
                break;
            default:
                $returnPathEmail = null;
                break;
        }

        if ($returnPathEmail !== null) {
            $mailTransport = new Zend_Mail_Transport_Sendmail("-f".$returnPathEmail);
            Zend_Mail::setDefaultTransport($mailTransport);
        }
        ...

When specifying to set the return path on a store's configuration, the case (1) is to read the sender e-mail from the object instance. Now getSenderEmail derives its value from either the store configuration ("Store Email Addresses" section), or if the caller explicitly set sender data.

And, of course, notice the unescaped-append of $returnPathEmail to the -f argument. That's the root of the vulnerability.

We would typically see this happen on the use of sibling method sendTransactional, where if the $sender argument is an array, then whatever is in that array will be used to determine the return path.

So you can see that it comes down to the code serving and routing a frontend form which can be at fault. Concerning Magento core code dealing with this, I haven't done an exhaustive search, but knowing that the sender is generally set from a transactional email, I can search a code base with a simple command:

grep -A2 -rn 'sendTransactional' /path/to/magento/app/code/core/

And if the second argument could be an array, then I might have cause for concern.