*Published: June 2024 | Author: SecureBytes Blog Team*


Summary:
A recent CVE—CVE-2024-4438—reveals a security gap in the etcd package distributed with the Red Hat OpenStack platform. This vulnerability traces back to an incomplete patch meant to address CVE-2023-39325 and CVE-2023-44487, which are known as "Rapid Reset" attacks. The main problem is an outdated dependency: etcd in this context compiles against an unsafe version of the http2 package (golang.org/x/net/http2) instead of using the patched system package from Red Hat Enterprise Linux (RHEL). This post breaks down the bug, explains why it happens, gives you code context, and shows what needs to be done to secure your OpenStack environments.

What is Rapid Reset?

The "Rapid Reset" attack (CVE-2023-39325, CVE-2023-44487) impacted many HTTP/2 servers around the world in 2023. Attackers could rapidly send and cancel large numbers of HTTP/2 requests (stream resets), overloading backends and causing denial of service.

The fixes for these CVEs involved updating how the HTTP/2 implementation in Golang handled such resets—basically by limiting inflight requests and shoring up protocol logic.

Original advisories:
- CVE-2023-39325
- CVE-2023-44487

Where Did the Patch Go Wrong?

Red Hat OpenStack, like many cloud platforms, relies on etcd for distributed configuration. The OpenStack etcd package is built using the Golang language, which fetches its dependencies as Go modules.

Red Hat patched the golang/x/net/http2 library in Red Hat Enterprise Linux. Any in-distro Go binaries that use the system library are therefore protected.
But: The etcd package inside OpenStack does not use the RHEL system library! Instead, it includes its own Go module dependency from upstream—potentially an out-of-date and vulnerable codebase.

Thus, OpenStack users may think they’re protected (thanks to the RHEL patch), but if etcd is compiled with a vulnerable golang.org/x/net/http2, the Rapid Reset attack still works.

Exploit Details: How an Attacker Could Use This

If your OpenStack cluster uses the vulnerable build of etcd, and is exposed on a public or semi-public network, an attacker can:

1. Make many HTTP/2 connections to the etcd API endpoint

Flood the etcd process, causing excessive CPU and memory

4. Degrade or knock out OpenStack services relying on etcd (API timeouts, service failures, cluster instability)

Sample exploitation (using curl and nghttp2)

# Example: Using nghttp to rapidly reset streams
nghttp -v -n 10000 -r https://TARGET_ETCD:2379/v2/keys/mykey

This command opens 10,000 streams and resets them, which if unprotected, can exhaust etcd’s handler pool.

Here’s a practical check using Go module files to see what version gets built into your etcd

# In your etcd source tree:
cat go.mod | grep 'golang.org/x/net'

You might see

golang.org/x/net v.9. // <--- vulnerable version!

Check the go.sum too for actual hash.

A patched system build would use a newer, fixed version—or, in RHEL’s case, the *system* library. But if the output looks like the above, you’re not protected!

What Should You Do?

The fix is NOT to update the OS, but to update the Go dependency at build time.

Locate go.mod in your etcd source.

- Change the version of golang.org/x/net/http2 to one containing the Rapid Reset patch (v.17. or newer).

`go

// In go.mod
replace golang.org/x/net v.9. => v.17.

`bash

go get golang.org/x/net@v.17.

References

- Red Hat Security Advisory RHSA-2024:XXXX* *(Link will update when advisory is public)*
- Go HTTP/2 Rapid Reset Patch PR
- etcd GitHub

Key Takeaways

- CVE-2024-4438 exposes OpenStack clusters using the bundled etcd package due to a supply-chain blind spot: the build-time version of golang.org/x/net/http2 matters.
- "We're running on RHEL 8/9" is not enough if your Go program is statically building upstream dependencies.
- Always check Go modules and update them if your software compiles its own dependencies instead of using system-wide libraries.


Stay safe, secure your builds, and make sure dev and ops teams talk to each other about how software is *actually* packaged!

*(This post is exclusive to SecureBytes Blog; re-use requires attribution. For up-to-date details, watch your vendor advisories and security mailing lists.)*

Timeline

Published on: 05/08/2024 09:15:09 UTC
Last modified on: 06/04/2024 17:54:33 UTC