Bug 772720 (CVE-2012-0039)

Summary: CVE-2012-0039 glib2: hash table collisions CPU usage DoS
Product: [Other] Security Response Reporter: Vincent Danen <vdanen>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: herrold, kseifried, mclasen, pachoramos1
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard: impact=moderate,public=20030529,reported=20120108,source=debian,cvss2=5.0/AV:N/AC:L/Au:N/C:N/I:N/A:P,rhel-4/glib2=affected,rhel-5/glib2=affected,rhel-6/glib2=affected,fedora-all/glib2=affected
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Bug Depends On:    
Bug Blocks: 770929    

Description Vincent Danen 2012-01-09 14:08:46 EST
It was reported [1] (and the original report [2]) that glib2 also suffers from algorithmic complexity attacks as described in oCERT-2011-003.  While this was originally reported to upstream in 2003, it does not look as though anything was done to correct the problem.  According to the Debian report, current glib2 is still vulnerable.

Doing a lookup on other g_str_hash() functions, the following packages may also be vulnerable if they copied code from glib2:

arts-1.5.10/flow/gsl/gslglib.c:172: guint g_str_hash (gconstpointer key)
gettext-0.17/gettext-tools/gnulib-lib/glib/gstring.c:97: g_str_hash (gconstpointer v)
pkg-config-0.23/glib-1.2.10/gstring.c:72: g_str_hash (gconstpointer key)

In addition to the above, the following are also in Red Hat Enterprise Linux 4:

glib-2.12.9/glib/gstring.c:91: g_str_hash (gconstpointer v) (in frysk)
glib-2.12.3/glib/gstring.c:91: g_str_hash (gconstpointer v) (in evolution28-glib2)

And Fedora has a lot more:

glib-1.2.10/gstring.c:72: g_str_hash (gconstpointer key)
gnucash-2.4.7/src/libqof/qof/qofutil.c:275: static guint g_str_hash_KEY(gconstpointer v)
libspectrum-1.0.0/myglib/ghash.c:253: g_str_hash (gconstpointer v
mono-2.10.5/eglib/src/ghashtable.c:598: g_str_hash (gconstpointer v1)
gettext-0.17/gettext-tools/gnulib-lib/glib/gstring.c:97: g_str_hash (gconstpointer v) (in mingw32-gettext)
gettext-0.17/gnulib-local/lib/glib/gstring.c:97: g_str_hash (gconstpointer v) (in mingw32-gettext)
glib-2.28.6/glib/gstring.c:137: g_str_hash (gconstpointer v) (in mingw32-glib)
nntpgrab-0.7.0/glue/glue_json.c:493: ng_str_hash (gconstpointer v)
Pacemaker-1-1-Pacemaker-1.1.6/lib/common/utils.c:2627: g_str_hash_traditional(gconstpointer v)
pacemaker-cloud-0.4.1/src/pcmk_pe.c:133: g_str_hash_traditional_copy(gconstpointer v)
qof-0.7.5/qof/qofutil.c:363: g_str_hash_KEY (gconstpointer v)
tucnak2-2.31/src/error.c:246: void dbg_str_hash(GHashTable *hash){

Some of these may be nothing, (just doing a search for functions with the string g_str_hash), but they probably need to be looked at to rule them out.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=655044
[2] http://mail.gnome.org/archives/gtk-devel-list/2003-May/msg00111.html
Comment 1 Matthias Clasen 2012-01-10 08:51:54 EST
The hash function implemented by g_str_hash is part of the documented api, and cannot just be changed. Every user of GHashTable is free to use its own hash functions, they are not hardwired at all.

So I don't really see what fix there is in glib; if anything, it could offer an alternative string hash function.
Comment 2 Vincent Danen 2012-01-11 21:24:28 EST
Do you know if upstream is discussing this further?  It looks like previously they had called for a volunteer to implement it, and no one ever responded (it didn't sound like it was technically a no-no, just probably quite painful to do).

I don't really know the best solution here, but we should perhaps get upstream involved in a conversation about how to deal with this (especially considering how old it is).  Maybe it is something that we just cannot (reasonably) fix?