Summary: | dev-libs/glib <2.16.6-r1 g_base64_encode heap-based buffer overflow (CVE-2008-4316) | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Gentoo Security | Reporter: | Robert Buchholz (RETIRED) <rbu> | ||||||
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> | ||||||
Status: | RESOLVED FIXED | ||||||||
Severity: | normal | CC: | gnome | ||||||
Priority: | High | ||||||||
Version: | unspecified | ||||||||
Hardware: | All | ||||||||
OS: | Linux | ||||||||
URL: | http://www.ocert.org/advisories/ocert-2008-015.html | ||||||||
Whiteboard: | A2? [glsa] | ||||||||
Package list: | Runtime testing required: | --- | |||||||
Attachments: |
|
Description
Robert Buchholz (RETIRED)
2008-11-29 01:43:07 UTC
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 |