Bug#984969: glib2.0 CVE-2021-27218, CVE-2021-27219, CVE-2021-28153: DSA or s-p-u?

[Salvatore Bonaccorso]

Hi Simon,

On Sun, Mar 21, 2021 at 02:03:24PM +0000, Simon McVittie wrote:
> glib2.0 2.66.6 and 2.66.8 fixed some security issues, listed here as
> most-severe-first (in my opinion):
> 
> * CVE-2021-28153 (#984969)
>   When g_file_replace() with G_FILE_CREATE_REPLACE_DESTINATION is asked
>   to overwrite a dangling symlink, in the vulnerable versions of GLib,
>   the target of the symlink gets created as an empty regular file as a
>   side-effect. If a malicious archive (e.g. tarball) is unpacked with
>   file-roller, this can be exploited to create an empty file in an
>   attacker-controlled location.
> 
>   Mitigation: the attacker cannot choose the file's contents or empty
>   an existing file, so this is only interesting if they are creating
>   a flag-file whose mere presence or absence is what matters, like
>   /etc/staff-group-for-usr-local.
> 
>   The patches I've proposed for this include a later follow-up fix to
>   error handling, which is not in bullseye/unstable yet (although I've
>   asked for permission to include it in #985610).
> 
> * CVE-2021-27219 (#982778)
>   On 64-bit platforms, if a buffer of length n > 4 GB is copied into a
>   new GBytes object, only the first (n % (1<<32)) bytes get allocated and
>   copied, but the new GBytes object still thinks it has length n, which
>   can result in undefined behaviour. The only known exploit for this is
>   memory corruption that crashes policykit-1's setuid polkit-agent-helper-1
>   with an assertion failure (a denial of service) but there might be
>   cases where an attacker can do something worse with this.
> 
>   While fixing this, the GLib developers also fixed similar issues where
>   the same function g_memdup() was called elsewhere in GLib. Most of them
>   are clearly not exploitable (either the length is fixed and small,
>   or an attacker-specified length would be silly for other reasons)
>   but some might be.
> 
>   In some of the places where changes were made, it's easy to see that the
>   changes are correct and harmless. Luckily, this includes CVE-2021-27219
>   itself. However, some of the other changes were non-trivial and caused
>   regressions that had to be fixed in 2.66.7.
> 
>   To minimize regression risk, I am proposing that we only fix the
>   easy cases in Debian 10, and deliberately leave the harder/more
>   regression-prone places unfixed, unless someone can explain how the
>   lengths can realistically become attacker-controlled and 4GB+. I talked
>   to upstream maintainer Philip Withnall about this and he agrees with
>   my reasoning.
> 
> * CVE-2021-27218 (#982779)
>   Similar to CVE-2021-27219, if a buffer of length n > 4 GB is copied into
>   a new GByteArray object, there's an integer overflow. No known exploit.
>   The fix turns this into a critical warning and NULL return, which
>   could still cause a crash (denial of service), but is the best we can
>   do within the constraints of the existing API/ABI.
> 
> Note that just to be extra-confusing, MITRE allocated consecutive CVE IDs
> for the two integer overflows, but assigned the first CVE ID to the issue
> that was reported second.
> 
> Proposed changes are available here:
> https://salsa.debian.org/gnome-team/glib/-/merge_requests/11
> 
> Do the security team want to do a DSA for this, or should I be talking to
> the stable release team?
> 
> If we go via a stable point release, I'm aware that I've narrowly missed
> the window for Debian 10.9, but that might be for the best: none of this
> seems amazingly urgent, and lots of things use GLib, so regressions here
> would be really bad.
> 
> Sorry this has taken a while to prepare, but at this point GLib 2.58 is
> 2½ years behind upstream's oldest supported branch, so the amount of
> backporting involved is significant, and that made me extra-cautious about
> regressions.

Thanks for the detailed overview and working on those issues for
buster!

Personal opionon: I do not think those issues need a DSA and can go in
via the 10.10 point release later on. Doing so has as well the
advantage that the upload could be staged long enough in
proosed-updates, it will though probably not have an enormous amount
of testers, but we can take advantage there as well for some
additional QA tests running.

So I would propose to mark those all no-dsa for buster and do an
update for the 10.10 point release.

Regards,
Salvatore