Bugzilla Bug 249214

** Please note that this issue is confidential and no information should be
disclosed until it is made public, see "Whiteboard" for a date **

oCERT informed us about the following vulnerability:

Base64 encoding and decoding functions in glib suffer from
vulnerabilities during memory allocations which may result in arbitrary
code execution when processing large strings.

g_base64_encode and g_base64_decode allocate memory for their respective
behavior using a similar pattern:

  ret = g_malloc0 (input_length * 3 / 4);

In g_base64_decode, input_length is typed as a gint and its value is
derived directly from a strlen(3) call over an input string.  Since the
multiplication is evaluated prior to the division, an input_length
greater than (UINT_MAX/3), or 1431655765, will wrap resulting in smaller
allocation than required.  It is also possible to achieve the same
effect with a carefully calculated signedness overflow, like -1/4 = 0.

In g_base64_encode, input_length (or 'len' in this case) is of type
gsize.  This suffers from the same overflow as above, but without the
signedness issue.  In addition, gsize's width changes by platform which
will affect the overall reach of an encoding overflow.  However, the
decoding buffer overflow is a more likely target due to the immediate
control of the output data when overwriting the heap metadata.

Patch and embargo timeline to be discussed.

FYI, dev-util/pkgconfig needs to be checked because it bundles glib 1.2.x

I think g_mime was only implemented in 2.0

Isn't that g_base64_* stuff? None of that is used in pkg-config at least, the
static copy has only a few files, base64 ones not part of it, and pkg-config
code itself doesn't have any references to "64" and based on pkg-config
functionality I don't see a place where it would make sense to use such stuff
anyways. So this ones clear and safe

Any news on the patch or embargo date?

No word from upstream yet, a patch has been proposed on Friday and the targeted
embargo date is middle of January next year. I'll attach the patch here as soon
as we have an upstream ack.

Created an attachment (id=178655) [details]
glib2-CVE-2008-4316.patch

Matthias Clasen (who apparantly is part of the glib upstream) approved of the
attached patch by Tomas Hoger of RedHat. Please test and prepare an ebuild,
attach it to this bug. Do not commit anything to CVS, we will do prestable
testing here.

upstream is targeting for the first week of march to lift the embargo and has
underlined that the patch is ok and will be applied in 2.20 to be released
around that time as well.
leio/remi, can we get it applied on our current stable? Please attach an ebuild
to this bug so we can test it before then. Thanks.

Taking the liberty to CCing Daniel and Gilles here, as I will not be able to
prepare an ebuild for glib-2.16 early enough considering the disclosure date
(will be on devaway for a week or so), and I trust their security handling and
not telling anything about this confidential bug outside here until it is
announced here to have been publicly disclosed.

I should be back around the time of the current preliminary disclosure date
though.

Created an attachment (id=183385) [details]
ebuild using above patch

Here's an ebuild for glib-2.16.2-r1 using the above patch.  I've tested it on a
stable amd64 system.

Arch Security Liaisons, please test the attached ebuild and report it stable on
this bug.
Target keywords : "alpha amd64 arm hppa ia64 m68k ppc ppc64 s390 sh sparc x86"

CC'ing current Liaisons:
   alpha : yoswink, armin76
   amd64 : keytoaster, tester
    hppa : jer
     ppc : dertobi123
   ppc64 : corsair
   sparc : fmccor
     x86 : maekke, armin76

Looks fine on sparc (all tests pass).

HPPA is OK.

Note that there is a typo in the attachment comment and it should get saved and
used as glib-2.16.6-r1.ebuild as the attachment name is.

Won't we need to pre-stable a 2.18 revision as well because 2.18 is under
stabilization right now?

(In reply to comment #15)
> Won't we need to pre-stable a 2.18 revision as well because 2.18 is under
> stabilization right now?

From what I see, arches are not yet CC'ed on that bug report. Since this bug is
going to be public soon (no clear date yet), can the 2.18 stabling just wait
until then?
The first 2.18 ebuild revision to carry the patch would be the target for
regular stabling then.

target date has been pushed to next week, possibly 2009-03-12.

(In reply to comment #16)
> (In reply to comment #15)
> > Won't we need to pre-stable a 2.18 revision as well because 2.18 is under
> > stabilization right now?
> 
> From what I see, arches are not yet CC'ed on that bug report. Since this bug is
> going to be public soon (no clear date yet), can the 2.18 stabling just wait
> until then?
> The first 2.18 ebuild revision to carry the patch would be the target for
> regular stabling then.

Arches are CC'ed on full GNOME-2.24 stabilization and the list there includes
glib-2.18

(In reply to comment #18)
> Arches are CC'ed on full GNOME-2.24 stabilization and the list there includes
> glib-2.18

Oh, I was looking at bug 253934, but it seems the action is on bug 260063 now.
Feel free to add a 2.18 ebuild to this bug for testing by Arch Liaisons.

This is now public and committed to upstream SVN:
http://svn.gnome.org/viewvc/glib?view=revision&revision=7973

The prestable process was not too successful, but please commit with the
gathered keywords and leave a comment once fixed versions are in the tree for
the other arches to stable.

a little bit late, but 2.16.6-r1 looks good on ppc.

2.16.6-r1 is in with sparc, hppa, and ppc stable.
2.18.4-r1 is in with amd64 stable.

Arches, please test and mark stable:
=dev-libs/glib-2.16.6-r1
Target keywords : "alpha amd64 arm hppa ia64 m68k ppc ppc64 s390 sh sparc x86"
Already stabled : "hppa ppc sparc"
Missing keywords: "alpha amd64 arm ia64 m68k ppc64 s390 sh x86"

=dev-libs/glib-2.18.4-r1
Target keywords : "alpha amd64 arm hppa ia64 m68k ppc ppc64 s390 sh sparc x86"
Already stabled : "amd64"
Missing keywords: "alpha arm hppa ia64 m68k ppc ppc64 s390 sh sparc x86"

CVE-2008-4316 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-4316):
  Multiple integer overflows in glib/gbase64.c in GLib before 2.20
  allow context-dependent attackers to execute arbitrary code via a
  long string that is converted either (1) from or (2) to a base64
  representation.

ppc64 done

amd64/x86 stable

Both stable on alpha.

m68k stable, thanks to kolla for testing

ppc done

HPPA is already stable except for 2.18.4-r1 which will be done through bug
#260063.

arm/ia64/s390/sh/sparc stable

GLSA 200904-02