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: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> |
| Status: | CLOSED ERRATA | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | unspecified | CC: | herrold, mclasen, pachoramos1 |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-10-19 21:51:17 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 770929 | ||
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. 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? |
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