Bug#868170: libemail-address-perl: Email::Address->parse() is vulnerable to CVE-2015-7686

[Pali Rohár]

On Thursday 18 January 2018 18:16:44 gregor herrmann wrote:
> On Thu, 18 Jan 2018 18:10:38 +0100, Pali Rohár wrote:
> 
> > > Thinking about upstream, I had another idea: If Email-Address is
> > > unmaintained on the CPAN, you could take it over (request co-maint)
> > > and then
> > > - change Email::Address to a wrapper around Email::Address::XS;
> > > - or remove the Email-Address distro and move the Email::Address
> > >   module, again changed to a wrapper, into the Email-Address-XS
> > >   distribution;
> > > - or, maybe least controversial, improve Email::Address to load
> > >   Email::Address::XS if it's installed. In that case we could in
> > >   Debian just add a dependency on libemail-address-xs-perl to
> > >   libemail-address-perl.
> > 
> > I had a discussion about Email::Address module and decision was to not
> > do such things as Email::Address is pure Perl module and
> > Email::Address::XS needs C compiler. There are lot of Perl systems where
> > C compiler is not available and there only pure Perl modules can be
> > installed/loaded.
> 
> I totally see this point; that's why I added my third proposal above
> and marked it as least controversial ("use ::XS if it is available").
> This would fix the issue in Debian, because here we can guarantee it
> by a dependency, and it would at least improve the situation for
> parts of rest of the world (the part which has a C compiler).

This does not fix the issue completely. Email::Address module exports
"vulnerable" regexes, see:
https://metacpan.org/source/RJBS/Email-Address-1.908/lib/Email/Address.pm#L126

And these regexes are not provided by Email::Address::XS module (as XS
module parses email by own sequential parser).

So it is better to not load Email::Address at all when application is
known to work correctly with Email::Address::XS to prevent usage of
insecure regexes.

-- 
Pali Rohár
pali.rohar at gmail.com