[oss-security] GLib (2.20.0+): GVariant, GDBus and GMarkup out of bounds reads, DoS and unbounded recursion

[Philip Withnall]

Hello,

Various fixes to GVariant, GDBus and GMarkup have just been pushed to
GLib, to deal with several problems kindly found in them by the oss-
fuzz project.

The fixes are here, with an explanation of each problem in the commit
messages:

https://gitlab.gnome.org/GNOME/glib/merge_requests/411

We are looking at doing backports to the glib-2-58 and glib-2-56
branches. They will be linked from the above merge request when
available, but will differ due to not being able to introduce new APIs.

We do not plan to make new tarball releases purely to include these
fixes. If you need to package the fixes, please pick them from the
merge request above.

It’s likely that the GVariant and GDBus implementations shipped in all
prior versions of GLib are affected. GVariant first shipped in GLib
2.20.0; GDBus in GLib 2.26.0. It’s also likely that the GMarkup code
has always been vulnerable. We have not verified the minimum bound of
the vulnerable versions, though.

In brief, the problems fixed are:
• Arithmetic underflow when calculating GVariant tuple element ends
resulting from missing validation of the offset table. This can result
in an out of bound read. Fixed by adding validation.
• Unbounded call recursion when handling highly recursive GVariant
types. This can result in a call stack overflow. Fixed by limiting
GVariant type recursion with static and dynamic types in untrusted
GVariant instances.
• Infinite loop when getting a child from a serialised variable array,
due to missing validation that the child offset does not point into the
offset table itself. Fixed by adding validation.
• Similarly for serialised tuples.
• nul bytes could pass through UTF-8 validation for long GVariant
strings due to a signed/unsigned mismatch. Fix: add a new validation
function which operates on an unsigned string length.
• Critical warning when parsing a D-Bus message with the wrong type
for its signature field in its message header. Fix: validate the type
before unwrapping that field.
• Critical warning when parsing a D-Bus message with a header field
containing a variant with an empty type signature, due to a mismatch
between validation of D-Bus type signatures and validation of GVariant
type strings. Fix: validate that the field is a valid type string too.

Philip