CVE-2023-45286 in go-resty
Summary
by MITRE • 11/28/2023
A race condition in go-resty can result in HTTP request body disclosure across requests. This condition can be triggered by calling sync.Pool.Put with the same *bytes.Buffer more than once, when request retries are enabled and a retry occurs. The call to sync.Pool.Get will then return a bytes.Buffer that hasn't had bytes.Buffer.Reset called on it. This dirty buffer will contain the HTTP request body from an unrelated request, and go-resty will append the current HTTP request body to it, sending two bodies in one request. The sync.Pool in question is defined at package level scope, so a completely unrelated server could receive the request body.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 12/20/2023
The vulnerability identified as CVE-2023-45286 represents a critical race condition within the go-resty HTTP client library that can lead to unauthorized data disclosure across HTTP requests. This flaw specifically manifests when the library employs sync.Pool for managing *bytes.Buffer objects while handling request retries, creating a scenario where concurrent operations can result in sensitive information leakage. The vulnerability is classified under CWE-362, which addresses race conditions in software systems, and aligns with ATT&CK technique T1566.001 for credential access through network sniffing and data exfiltration. The root cause stems from improper handling of shared resources within the library's internal buffer management system, where the sync.Pool mechanism fails to properly reset buffer states between reuse cycles.
The technical implementation of this vulnerability exploits the concurrent nature of HTTP request processing in applications using go-resty with retry mechanisms enabled. When a request fails and triggers a retry, the library attempts to reuse a previously allocated *bytes.Buffer from the sync.Pool through sync.Pool.Get. However, if the same buffer is returned to the pool via sync.Pool.Put multiple times without proper reset operations, subsequent requests may encounter a buffer that still contains data from previous operations. This occurs because sync.Pool does not automatically call Reset() on returned buffers, leaving residual data that can be inadvertently appended to new request bodies. The flaw becomes particularly dangerous when request retries are enabled, as the probability of encountering the same buffer increases significantly during concurrent request processing, creating a scenario where the same buffer instance might be reused for completely different requests.
The operational impact of CVE-2023-45286 extends beyond simple data leakage to encompass potential security breaches and compliance violations in environments where sensitive information flows through HTTP requests. An attacker could potentially intercept or manipulate HTTP requests to inject data from one request into another, leading to unauthorized data disclosure, session hijacking, or even cross-site request forgery attacks. The vulnerability affects any application using go-resty with retry functionality enabled, making it particularly concerning for enterprise applications and microservices architectures where such patterns are common. The risk is amplified by the fact that the affected buffers are defined at package level scope, meaning that the buffer contamination could potentially affect unrelated services or even completely different servers if the same buffer instance is reused across different request contexts. This cross-contamination aspect makes the vulnerability particularly insidious as it can compromise data integrity across multiple system boundaries.
Mitigation strategies for CVE-2023-45286 require immediate attention through library updates and code modifications to address the underlying race condition. The most effective approach involves updating to a patched version of go-resty that properly implements buffer reset mechanisms before returning objects to the sync.Pool. Organizations should also consider implementing additional safeguards such as disabling retry mechanisms for sensitive requests or using alternative HTTP client libraries that do not exhibit this behavior. Security teams should monitor network traffic for unusual request patterns that might indicate buffer contamination, as this vulnerability may not always produce immediately obvious errors but could result in subtle data leakage. Additionally, implementing proper input validation and output sanitization measures can help detect and prevent exploitation attempts, while regular security audits of HTTP client usage patterns can identify potential exposure points. The vulnerability highlights the importance of proper resource management in concurrent programming environments and underscores the need for comprehensive testing of shared resource handling in network libraries.