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
