** 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 attachment 178655 [details, diff] 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 attachment 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
