[Pkg-roundcube-maintainers] Security issues in roundcube 1.2.3+dfsg.1-4+deb9u3 and 1.3.10+dfsg.1-1~deb10u1

[Salvatore Bonaccorso]

Hi Guilhem,

On Wed, May 06, 2020 at 02:07:30PM +0200, Guilhem Moulin wrote:
> Hi carnil,
> 
> On Wed, 06 May 2020 at 05:54:59 +0200, Salvatore Bonaccorso wrote:
> > On Thu, Apr 30, 2020 at 12:36:11AM +0200, Guilhem Moulin wrote:
> >> In a recent mail roundcube webmail upstream has announced the following
> >> security fixes:
> >> 
> >>  - Cross-Site Scripting (XSS) via malicious HTML content
> >>  - CSRF attack can cause an authenticated user to be logged out
> >>    https://github.com/roundcube/roundcubemail/pull/7302
> >> 
> >> (Plus two more that are are irrelevant for Debian.)
> >> http://lists.roundcube.net/pipermail/announce/2020-April/thread.html
> > 
> > Have a question back on those. They got assigned in the last MITRE
> > feed update as CVE-2020-12640 and CVE-2020-12641 and are fixed thus
> > along as well with 1.4.4+dfsg.1-1 and 1.3.11+dfsg.1-1~deb10u1.
> 
> Ah yeah sorry, should have developed this a bit :-P
> 
> > But with "are irrelevant" do you mean here because the respective
> > settings 
> > 
> > $config['im_identify_path'] = null;
> > $config['im_convert_path'] = null;
> > 
> > in config/defaults.inc.php are here under admins control?
> 
> Indeed AFAICT one would need to set $config['im_identify_path'] or
> $config['im_convert_path'] to a string containing shell metacharacters
> in order to exploit CVE-2020-12641, and the config file is created with
> ownership root:www-data and mode 0640 by default.
> 
> Similarly in order to exploit CVE-2020-12640 one would need to set
> $config['plugins'] to array containing an insecure plugin name, which is
> only doable by the local admin unless they changed the file's ownership
> and/or permissions.  (At which point I'd say they have other problems
> :-P)
> 
> Maybe I would have applied these commits to 1.2.3+dfsg.1-4+deb9u4
> nonetheless?  The commits [0,1] aren't intrusive after all.  I can
> prepare another upload if you think this warrants a DSA.

Thanks! Okay then I understood correctly. No I do not think we should
issue another DSA for those.  Actually I now with your above
explanation marked the issues as unimportant. 

Of course, you can include these fixes as well in either an
point-release update (the last one probably I guess for stretch) or in
a future DSA.

Thanks for taking time to outline/give background.

Regards,
Salvatore