CVE-2012-0039: High severity glib vulnerability
DISPUTED GLib 2.31.8 and earlier, when the gstrhash function is used, computes hash values without restricting the ability to trigger hash collisions predictably, which allows context-dependent attackers to cause a denial of service (CPU consumption) via crafted input to an application that maintains a hash table. NOTE: this issue may be disputed by the vendor; the existence of the gstrhash function is not a vulnerability in the library, because callers of ghashtablenew and ghashtablenewfull can specify an arbitrary hash function that is appropriate for the application.
Other sources
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 gstrhash() functions, the following packages may also be vulnerable if they copied code from glib2:
arts-1.5.10/flow/gsl/gslglib.c:172: guint gstrhash (gconstpointer key) gettext-0.17/gettext-tools/gnulib-lib/glib/gstring.c:97: gstrhash (gconstpointer v) pkg-config-0.23/glib-1.2.10/gstring.c:72: gstrhash (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: gstrhash (gconstpointer v) (in frysk) glib-2.12.3/glib/gstring.c:91: gstrhash (gconstpointer v) (in evolution28-glib2)
And Fedora has a lot more:
glib-1.2.10/gstring.c:72: gstrhash (gconstpointer key) gnucash-2.4.7/src/libqof/qof/qofutil.c:275: static guint gstrhashKEY(gconstpointer v) libspectrum-1.0.0/myglib/ghash.c:253: gstrhash (gconstpointer v mono-2.10.5/eglib/src/ghashtable.c:598: gstrhash (gconstpointer v1) gettext-0.17/gettext-tools/gnulib-lib/glib/gstring.c:97: gstrhash (gconstpointer v) (in mingw32-gettext) gettext-0.17/gnulib-local/lib/glib/gstring.c:97: gstrhash (gconstpointer v) (in mingw32-gettext) glib-2.28.6/glib/gstring.c:137: gstrhash (gconstpointer v) (in mingw32-glib) nntpgrab-0.7.0/glue/gluejson.c:493: ngstrhash (gconstpointer v) Pacemaker-1-1-Pacemaker-1.1.6/lib/common/utils.c:2627: gstrhashtraditional(gconstpointer v) pacemaker-cloud-0.4.1/src/pcmkpe.c:133: gstrhashtraditionalcopy(gconstpointer v) qof-0.7.5/qof/qofutil.c:363: gstrhashKEY (gconstpointer v) tucnak2-2.31/src/error.c:246: void dbgstrhash(GHashTable hash){
Some of these may be nothing, (just doing a search for functions with the string gstrhash), 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
— Red Hat
Affected Software
Event History
Frequently Asked Questions
What is the severity of CVE-2012-0039?
CVE-2012-0039 has a medium severity rating as it allows attackers to exploit hash collisions to cause denial of service by overwhelming CPU consumption.
How do I fix CVE-2012-0039?
To fix CVE-2012-0039, ensure you update to GLib version 2.31.9 or later where the issue has been addressed.
What versions of GLib are affected by CVE-2012-0039?
CVE-2012-0039 affects GLib versions 2.31.8 and earlier, as well as several earlier versions including 1.x series.
How can CVE-2012-0039 be exploited?
CVE-2012-0039 can be exploited by sending crafted input to applications that use the g_str_hash function, leading to predictable hash collisions.
Is CVE-2012-0039 a critical vulnerability?
CVE-2012-0039 is not a critical vulnerability but can lead to significant performance issues due to CPU consumption in affected applications.