Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 772720 - (CVE-2012-0039) CVE-2012-0039 glib2: hash table collisions CPU usage DoS
CVE-2012-0039 glib2: hash table collisions CPU usage DoS
Status: NEW
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
: Security
Depends On:
Blocks: hashdos/oCERT-2011-003
  Show dependency treegraph
Reported: 2012-01-09 14:08 EST by Vincent Danen
Modified: 2018-06-29 17:59 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
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?

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