Hi Simon, On Wed, May 13, 2020 at 05:02:32PM +0100, Simon McVittie wrote: > On Wed, 13 May 2020 at 17:21:44 +0200, Salvatore Bonaccorso wrote: > > CVE-2020-12825[0]: > > | libcroco through 0.6.13 has excessive recursion in > > | cr_parser_parse_any_core in cr-parser.c, leading to stack consumption. > > Mitigation: here are the only things in >= stable that depend on libcroco: > > - gnome-shell, cinnamon: I don't think these parse untrusted CSS, only > CSS that comes from GNOME Shell itself or a Shell extension (which can > execute arbitrary code with the user's privileges *anyway*, so they're > inherently trusted). > > gnome-shell in unstable contains a cut-down fork of croco, in which > the developers are deleting unused code and redoing what's left in Rust, > using Mozilla's underlying parser; similar reasoning applies to that. > > cinnamon is basically a fork of an old version of GNOME Shell, so it's > still using libcroco. > > - gettext: seems to be part of term-styled-ostream, an ANSI terminal text > highlighting library[1], rather than parsing anything untrusted. > > There is a vendored copy included, but Debian uses the system copy. > > - librsvg in stable > > In unstable, librsvg was rewritten in Rust, using Mozilla's underlying > parser. > > - libccss in stable > > This package is unmaintained upstream and was removed from > testing/unstable. > > (I suspect the GNOME team might end up orphaning libcroco, now that no > GNOME components depend on it any more.) > > I think the only one of those that's potentially of interest from the > point of view of denial-of-service in a long-running process is librsvg in > stable, and even that seems more likely to be used as a batch-mode tool, > via imagemagick or rsvg-convert(1) or similar.
Thanks for your analysis and overview. FWIW, the issue was marked earlier no-dsa for stretch and buster, so if/whenever a fix arise might be enough to adress it via a point release. Regards, Salvatore
