[pkg-php-pear] Bug#850215: Bug#850215: zendframework: CVE-2016-10034

[Salvatore Bonaccorso]

Hi

On Thu, Jan 05, 2017 at 10:34:29AM +0100, Markus Frosch wrote:
> On 05.01.2017 07:01, Salvatore Bonaccorso wrote:
> > Source: zendframework
> > Version: 1.12.9+dfsg-1
> > Severity: grave
> > Tags: upstream security
> > Justification: user security hole
> > 
> > Hi,
> > 
> > the following vulnerability was published for zendframework.
> > 
> > CVE-2016-10034[0]:
> > | The setFrom function in the Sendmail adapter in the zend-mail
> > | component before 2.4.11, 2.5.x, 2.6.x, and 2.7.x before 2.7.2, and
> > | Zend Framework before 2.4.11 might allow remote attackers to pass
> > | extra parameters to the mail command and consequently execute
> > | arbitrary code via a \" (backslash double quote) in a crafted e-mail
> > | address.
> > 
> > If you fix the vulnerability please also make sure to include the
> > CVE (Common Vulnerabilities & Exposures) id in your changelog entry.
> > 
> > For further information see:
> > 
> > [0] https://security-tracker.debian.org/tracker/CVE-2016-10034
> >     https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-10034
> > 
> > Please adjust the affected versions in the BTS as needed.
> 
> Hi Salvatore,
> thanks for bringing that up.
> 
> I actually don't think this CVE is valid for ZendFramework 1 (Version < 2).
> 
> Not only there are big differences in class structure between ZF1 and ZF >= 2.0,
> but many features have been introduced first in ZF > 2.
> 
> I see no specific handling for a From header in Zend_Mail_Transport_Sendmail.
> 
> https://github.com/zendframework/zf1/blob/master/library/Zend/Mail/Transport/Sendmail.php#L128
> 
> A user of the library would be able to insert additional parameters, and pass whatever
> argument to sendmail. But the user would have to care about securing / escaping then.
> 
> As we currently don't have a package for Zend-Mail, and zendframework is < 2, this bug
> wouldn't affect Debian.
> 
> Would love if someone could approve or object my analysis.

Adding Thijs to the loop, who did some additional research, which
triggered us to change the status from <undetermined> to <unfixed> in
the security-tracker.

Regards,
Salvatore