CVE-2012-0039 in GLib
Summary
by MITRE
** 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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 03/04/2025
The vulnerability identified as CVE-2012-0039 relates to the GLib library version 2.31.8 and earlier, specifically concerning the g_str_hash function implementation. This issue exists within the core hashing mechanism that applications use to store and retrieve data efficiently through hash tables. The fundamental problem lies in the hash function's inability to prevent predictable hash collisions, creating a scenario where malicious actors can craft specific input data designed to exploit this weakness. From a cybersecurity perspective, this represents a classic denial of service vulnerability that can severely impact system availability and performance.
The technical flaw manifests when applications utilize the default g_str_hash function within their hash table implementations. This function computes hash values in a manner that does not adequately randomize or obscure the hash computation process, making it susceptible to collision attacks. Attackers can generate input data that deliberately creates hash collisions, forcing the hash table to degrade from optimal O(1) lookup performance to O(n) worst-case scenarios. When multiple hash collisions occur simultaneously, the hash table's internal structure becomes increasingly inefficient, leading to excessive CPU consumption and ultimately system resource exhaustion. This vulnerability operates under CWE-327, which addresses the use of weak cryptographic hash functions, and aligns with ATT&CK technique T1499.004 for network denial of service attacks.
The operational impact of this vulnerability extends beyond simple performance degradation to potentially compromising entire application availability. When exploited, malicious input can cause applications to consume excessive CPU cycles, leading to system slowdowns or complete service unavailability. This is particularly concerning for applications that rely heavily on hash tables for data management, such as web servers, database systems, and network services. The vulnerability's context-dependent nature means that exploitation requires specific conditions where applications use the default g_str_hash function without implementing custom collision-resistant hashing mechanisms. Organizations running affected versions of GLib must understand that even seemingly benign applications could be vulnerable if they depend on the default hash table behavior.
Mitigation strategies for this vulnerability involve multiple layers of defense and system hardening approaches. The primary recommendation is to upgrade to GLib versions beyond 2.31.8 where the hash function implementation has been improved to resist predictable collision attacks. Additionally, developers should implement custom hash functions when working with user-supplied data, ensuring that hash tables are configured with collision-resistant algorithms. Security practitioners should monitor applications for proper hash table configuration and consider implementing rate limiting or input validation mechanisms to prevent exploitation attempts. Organizations can also leverage runtime protections such as heap randomization and stack canaries to make exploitation more difficult. The vendor's stance that this is not a direct library vulnerability highlights the importance of proper application design and the principle that developers must consider security implications when selecting and configuring library functions. This vulnerability demonstrates the critical importance of understanding library behavior and implementing defensive programming practices, particularly when dealing with cryptographic or hash-related functions that can become attack vectors when improperly configured.