Bug 398359 (CVE-2012-0039) – dev-libs/glib : hash collision DoS (CVE-2012-0039)

• Product: Gentoo Security
• Status: RESOLVED CANTFIX

[Description Agostino Sarubbo 2012-01-10 10:54:24 UTC]

From redhat bugzilla at $URL:

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.

[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 Alexandre Rostovtsev (RETIRED) 2012-01-10 19:50:22 UTC]

If any glib-based libraries or applications use g_str_hash() to compare unbounded sets of strings from a potentially hostile source, they need to be fixed to use a different hash function.

Fixing g_str_hash() itself is probably not an option since upstream considers its algorithm to be part of the glib API (https://bugzilla.redhat.com/show_bug.cgi?id=772720#c1)

[Comment 2 Aaron Bauman (RETIRED) 2016-03-14 13:22:58 UTC]

** DISPUTED ** GLib 2.31.8 and earlier, when the g_str_hash 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 g_str_hash function is not a vulnerability in the library, because callers of g_hash_table_new and g_hash_table_new_full can specify an arbitrary hash function that is appropriate for the application.