CVE-2023-45286: Race Condition in Go-Resty Library Discloses HTTP Request Bodies Across Requests

Summary: This article is intended to provide an overview and explanation of CVE-2023-45286, a race condition found in the go-resty (v2.3.) library. This vulnerability can lead to the exposure of HTTP request bodies across requests, posing a security risk to your application implementations.

Background

Go-Resty is a popular and easy-to-use HTTP and RESTful client library written in Go programming language. The vulnerability was identified in both v2.3. and earlier versions of the library. A race condition is a situation in which the behavior of a software application can depend on the relative timing of events, such as the order in which threads are scheduled to run. The vulnerability can be triggered by a specific sequence of events involving Go-Resty and the Go's sync.Pool package.

Issue Details

The issue involves a race condition existing in go-resty's handling of the sync.Pool package resulting in HTTP request body disclosure across requests. Specifically, 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.

Afterward, calling sync.Pool.Get will return a bytes.Buffer that hasn't had the mandatory 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 - the dirty buffer and the new request body - in a single request.

Here's a piece of code that demonstrates this issue

func doRequest() {
  client := resty.New()
  client.SetRetryCount(1)
  client.NewRequest().SetBody({"xx": "11223344"})

  resp, err := client.R().Post("https://example.com";)
  if err != nil {
    log.Println("Request failed:", err)
    return
  }
  log.Println("Response status code:", resp.StatusCode())
}

The sync.Pool in question is defined at the package level scope, which means even a completely unrelated server could receive the request body, posing a serious security risk for applications using the go-resty library.

Mitigation and Remediation

Developers who have the go-resty library included in their projects should take the following steps to address this vulnerability:

1. Upgrade to the latest version of the go-resty library, which includes all available stability, security, and performance improvements.

2. Review your application code and disable retries or ensure that there's a sufficient gap between retries such that this race condition would be hard to trigger.

Further References and Reading

- Go-Resty Direct Download: https://github.com/go-resty/resty/releases
- Go-Resty Official Documentation: https://go-resty.github.io/resty/
- CVE Details: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-45286
- Go Slices and Sync.Pool usage examples: https://go.dev/play/p/LVOLPQlVRz5

Conclusion

This article highlights the race condition vulnerability in go-resty, CVE-2023-45286, leading to the unintended disclosure of HTTP request bodies across requests. Developers using the go-resty library should apply appropriate mitigation strategies as suggested to avoid any potential security breaches. Keep up to date with the latest security advisories and stay vigilant.

Timeline

Published on: 11/28/2023 17:15:08 UTC
Last modified on: 01/04/2024 19:15:08 UTC