Bug 772720 (CVE-2012-0039) - CVE-2012-0039 glib2: hash table collisions CPU usage DoS
Summary: CVE-2012-0039 glib2: hash table collisions CPU usage DoS
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2012-0039
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: hashdos, oCERT-2011-003
TreeView+ depends on / blocked
 
Reported: 2012-01-09 19:08 UTC by Vincent Danen
Modified: 2021-10-19 21:51 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-10-19 21:51:17 UTC
Embargoed:


Attachments (Terms of Use)

Description Vincent Danen 2012-01-09 19:08:46 UTC
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 13:51:54 UTC
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-12 02:24:28 UTC
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?


Note You need to log in before you can comment on or make changes to this bug.