CVE-2024-48924 in MessagePack-CSharp
Summary
by MITRE • 10/18/2024
### Impact
When this library is used to deserialize messagepack data from an untrusted source, there is a risk of a denial of service attack by an attacker that sends data contrived to produce hash collisions, leading to large CPU consumption disproportionate to the size of the data being deserialized.
This is similar to [a prior advisory](https://github.com/MessagePack-CSharp/MessagePack-CSharp/security/advisories/GHSA-7q36-4xx7-xcxf), which provided an inadequate fix for the hash collision part of the vulnerability.
### Patches
The following steps are required to mitigate this risk.
1. Upgrade to a version of the library where a fix is available. 1. Review the steps in [this previous advisory](https://github.com/MessagePack-CSharp/MessagePack-CSharp/security/advisories/GHSA-7q36-4xx7-xcxf) to ensure you have your application configured for untrusted data.
### Workarounds
If upgrading MessagePack to a patched version is not an option for you, you may apply a manual workaround as follows:
1. Declare a class that derives from `MessagePackSecurity`. 2. Override the `GetHashCollisionResistantEqualityComparer` method to provide a collision-resistant hash function of your own and avoid calling `base.GetHashCollisionResistantEqualityComparer()`. 3. Configure a `MessagePackSerializerOptions` with an instance of your derived type by calling `WithSecurity` on an existing options object. 4. Use your custom options object for all deserialization operations. This may be by setting the `MessagePackSerializer.DefaultOptions` static property, if you call methods that rely on this default property, and/or by passing in the options object explicitly to any `Deserialize` method.
### References
- Learn more about best security practices when reading untrusted data with [MessagePack 1.x](https://github.com/MessagePack-CSharp/MessagePack-CSharp/tree/v1.x#security) or [MessagePack 2.x](https://github.com/MessagePack-CSharp/MessagePack-CSharp#security).
- The .NET team's [discussion on hash collision vulnerabilities of their `HashCode` struct](https://github.com/GrabYourPitchforks/runtime/blob/threat_models/docs/design/security/System.HashCode.md).
### For more information
If you have any questions or comments about this advisory:
* [Start a public discussion](https://github.com/MessagePack-CSharp/MessagePack-CSharp/discussions)
* [Email us privately](mailto:[email protected])
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/18/2024
The vulnerability described in CVE-2024-48924 affects the MessagePack-CSharp library and represents a significant denial of service risk when processing untrusted data. This issue stems from the library's handling of hash collisions during messagepack deserialization, where maliciously crafted data can trigger excessive cpu consumption. The flaw operates by exploiting the underlying hash table implementation to create conditions where hash collisions occur frequently, leading to performance degradation that scales disproportionately with input size. This vulnerability is particularly concerning because it can be exploited remotely through network-based attacks against applications that deserialize messagepack data from external sources.
The technical nature of this vulnerability aligns with common security patterns found in hash table collision attacks, which are categorized under CWE-400 as "Uncontrolled Resource Consumption" and specifically relate to CWE-327 as "Use of a Broken or Risky Cryptographic Algorithm." The issue manifests when messagepack data structures contain keys that are designed to produce hash collisions in the internal data structures used by the library. This creates a scenario where the normal O(1) average case complexity for hash table operations degrades to O(n) in the worst case, resulting in exponential cpu usage as the number of colliding elements increases. The vulnerability impacts applications that deserialize data from untrusted sources, making it particularly dangerous in web applications, api endpoints, or any system that processes external messagepack payloads.
The operational impact of this vulnerability extends beyond simple performance degradation to potentially causing complete system unresponsiveness or resource exhaustion. Attackers can craft specific messagepack payloads that will cause the deserialization process to consume excessive computational resources, effectively creating a denial of service condition that can impact availability of services. This type of attack is particularly effective in cloud environments or containerized applications where resource limits are enforced, as the excessive cpu usage can cause applications to be terminated or throttled by resource management systems. The vulnerability also represents a risk to application stability, as it can cause unexpected crashes or memory exhaustion during deserialization operations.
Mitigation strategies for CVE-2024-48924 involve both immediate remediation and architectural considerations. The primary solution requires upgrading to a patched version of the MessagePack-CSharp library where the hash collision resistance has been properly implemented. Organizations should review their application dependencies and ensure all instances of the vulnerable library are updated to versions that contain the corrected hash collision handling mechanisms. The previous advisory referenced in the vulnerability report indicates that earlier fixes were inadequate, emphasizing the need for thorough verification of patch effectiveness. Manual workarounds are available for environments where immediate upgrades are not feasible, involving custom implementation of security measures through the MessagePackSecurity class and custom equality comparers. These workarounds require careful implementation to avoid introducing new vulnerabilities while providing temporary protection against the attack vector.
Security practitioners should also consider the broader implications of this vulnerability within their application security posture. The issue highlights the importance of proper input validation and sanitization when processing data from untrusted sources, aligning with security frameworks such as the OWASP Top Ten and NIST cybersecurity guidelines. The vulnerability demonstrates how seemingly innocuous serialization libraries can become attack vectors when not properly secured against hash collision attacks. Organizations should implement monitoring and alerting mechanisms to detect unusual cpu usage patterns that might indicate exploitation attempts, particularly in systems that deserialize messagepack data. The .NET runtime's own documentation on hash collision vulnerabilities provides additional context for understanding how these attacks work at the underlying implementation level, reinforcing the need for careful consideration of cryptographic and hashing functions in application design. This vulnerability serves as a reminder of the critical importance of maintaining up-to-date security practices and the potential for indirect attacks through commonly used third-party libraries.