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