Bug#1028475: Backport recent GVariant security fixes to Stable

[Simon McVittie]

Control: tags -1 + security

On Wed, 11 Jan 2023 at 16:37:01 +0000, Philip Withnall wrote:
> Are there plans to backport the recent GVariant security fixes to
> Debian Stable?
> 
> These are:
>  - https://gitlab.gnome.org/GNOME/glib/-/issues/2782
>  - https://gitlab.gnome.org/GNOME/glib/-/issues/2121
>  - https://gitlab.gnome.org/GNOME/glib/-/issues/2540
>  - https://gitlab.gnome.org/GNOME/glib/-/issues/2794
>  - https://gitlab.gnome.org/GNOME/glib/-/issues/2797
>  - https://gitlab.gnome.org/GNOME/glib/-/issues/2840
>  - https://gitlab.gnome.org/GNOME/glib/-/issues/2841
> 
> In addition, these two issues have highly related fixes (which it’s
> probably easiest to backport in the same tranche), but they are not
> security issues:
>  - https://gitlab.gnome.org/GNOME/glib/-/issues/2612
>  - https://gitlab.gnome.org/GNOME/glib/-/issues/2839
> 
> Apologies if a decision has been deliberately taken to not backport
> them, I don’t fully understand the criteria for what gets backported.

There are actually two sets of criteria for what gets backported to
stable. If the Debian security team (Cc'd) thinks an issue is sufficiently
serious to need a security advisory and an immediate release, then they
prepare a security update, either doing the work themselves or coordinating
with the package's maintainer for the actual code changes.

If the security team are not interested in an issue, but the package's
maintainer thinks the issue needs a stable update, then the package's
maintainer coordinates with the release team to get the change into the
next stable point release, which happens once per 1-2 months.

I think these issues are all denial-of-service, which the security team
usually treats as not sufficiently important for an advisory and an
off-schedule fix. Security team: do you agree, based on the information
quoted below? If yes, we can treat this as a low-priority security fix
(I would personally rate its severity at somewhere between important
and minor) and fix it in a point release later.

The diff is going to be quite large, and the initial round of fixes had
some regressions (one of which was significantly more serious than the
original issue), so I don't think we should rush this.

> There are two sets of risks in these issues:
> 
> 1. Denial of service caused by handling a malicious serialised variant
> which is structured to cause allocations or looping superlinear to its
> serialised size. Applications are at risk if they accept untrusted
> serialised variants by checking them with g_variant_get_normal_form()
> (or don’t check them). Applications which reject variants with
> g_variant_is_normal_form() first are not vulnerable. In order to be
> exploitable, the variant must have a dynamically typed component in it
> (i.e. a `v` type somewhere). This is typically as part of an `a{sv}`.
> 
> 2. Denial of service caused by handling a malicious text-form variant
> which is structured to cause looping superlinear to its text size.
> Applications are at risk if they parse untrusted text-form variants.
> 
> Scenario 2 is much less likely than scenario 1, as the GVariant text-
> form parser is not documented as suitable for use on untrusted input.
> Scenario 1 is likely because g_variant_get_normal_form() *is*
> documented as being safe to use on untrusted input.
> 
> Issue #2840 documents a heap buffer overflow, but this vulnerability
> was introduced as part of the fixes for the above two scenarious, so
> GLib is only vulnerable to the overflow if an incomplete set of patches
> are backported.

Issue #2840 is more serious, but Debian was never vulnerable to it, so
we can disregard that one (as long as we backport all the recent GVariant
fixes at once).

The rest are only denial-of-service, for which the worst-case impact
would be things like OSTree and Flatpak, which receive GVariants from
a remote server and load them into memory. OSTree/Flatpak are normally
used with a TLS (https) connection to a server that is at least partly
trusted (we're eventually going to run arbitrary code from it, either
sandboxed or not), so a malicious server could likely do worse than DoS
just by acting as designed, and a man-in-the-middle cannot alter what's
carried over the https connection. That doesn't seem high-severity to me.

    smcv