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

Simon McVittie smcv at debian.org
Sun Mar 21 14:03:24 GMT 2021


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.

    smcv



More information about the pkg-gnome-maintainers mailing list