CVE-2024-3177: Kubernetes Auth Bypass Vulnerability

CVE-2024-3177 Overview

A security issue was discovered in Kubernetes where users may be able to launch containers that bypass the mountable secrets policy enforced by the ServiceAccount admission plugin when using containers, init containers, and ephemeral containers with the envFrom field populated. The policy ensures pods running with a service account may only reference secrets specified in the service account's secrets field. Kubernetes clusters are only affected if the ServiceAccount admission plugin and the kubernetes.io/enforce-mountable-secrets annotation are used together with containers, init containers, and ephemeral containers with the envFrom field populated.

Critical Impact

Unauthorized access to secrets outside the permitted service account scope could lead to credential theft, lateral movement, or exposure of sensitive configuration data within affected Kubernetes clusters.

Affected Products

• Kubernetes clusters using ServiceAccount admission plugin
• Kubernetes deployments with kubernetes.io/enforce-mountable-secrets annotation
• Containers, init containers, and ephemeral containers utilizing the envFrom field

Discovery Timeline

• April 16, 2024 - Security issue disclosed via Openwall OSS-Security
• April 22, 2024 - CVE-2024-3177 published to NVD
• November 21, 2024 - Last updated in NVD database

Technical Details for CVE-2024-3177

Vulnerability Analysis

This vulnerability represents a policy bypass in Kubernetes' ServiceAccount admission plugin. The core issue lies in how the admission controller validates secret references when the envFrom field is used within pod specifications. Under normal circumstances, the ServiceAccount admission plugin enforces that pods can only access secrets explicitly listed in the associated service account's secrets field when the kubernetes.io/enforce-mountable-secrets annotation is applied.

However, the admission logic fails to properly validate secret references when they are specified through the envFrom mechanism in containers, init containers, and ephemeral containers. This creates a gap in the security enforcement where an attacker with the ability to create or modify pod specifications could reference secrets beyond those permitted by the service account policy.

The impact is limited to information disclosure of secrets that exist within the same namespace but should be restricted by the mountable secrets policy. Exploitation requires authenticated access with permissions to create or modify pods in the affected namespace.

Root Cause

The root cause is improper input validation (CWE-20) in the ServiceAccount admission plugin's secret reference checking logic. The plugin correctly enforces the mountable secrets policy for volume-mounted secrets but fails to apply the same validation when secrets are referenced via the envFrom field in container specifications. This oversight allows the envFrom mechanism to bypass the intended access control restrictions.

Attack Vector

The attack requires network access to the Kubernetes API server with high privileges (pod creation/modification permissions). An authenticated user with access to create pods in a namespace can craft a pod specification that uses the envFrom field to reference secrets that should be restricted by the kubernetes.io/enforce-mountable-secrets annotation on the service account. The referenced secrets' values would then be exposed as environment variables within the container, potentially leaking sensitive credentials or configuration data.

The exploit scenario involves:

1. Identifying a namespace where a service account has the kubernetes.io/enforce-mountable-secrets annotation
2. Creating a pod specification with the envFrom field referencing a secret not in the service account's permitted secrets list
3. Deploying the pod and accessing the secret values through environment variables

Detection Methods for CVE-2024-3177

Indicators of Compromise

• Pod specifications containing envFrom fields that reference secrets not listed in the associated service account's secrets field
• Audit log entries showing pod creation or updates with envFrom.secretRef configurations in namespaces using mountable secrets enforcement
• Unexpected environment variables containing sensitive data in container processes

Detection Strategies

• Enable Kubernetes audit logging and monitor for CREATE and UPDATE operations on pods that include envFrom configurations referencing secrets
• Implement OPA Gatekeeper or Kyverno policies to validate that all secret references in envFrom fields match the permitted secrets for the service account
• Review existing pods in namespaces where kubernetes.io/enforce-mountable-secrets is used for potential policy violations

Monitoring Recommendations

• Configure alerts for pod deployments that reference secrets via envFrom in namespaces with strict secret policies
• Implement runtime security monitoring using SentinelOne Singularity for Cloud Workloads to detect anomalous secret access patterns
• Regularly audit service account configurations and their associated pods for compliance with intended secret access policies

How to Mitigate CVE-2024-3177

Immediate Actions Required

• Review all namespaces using the kubernetes.io/enforce-mountable-secrets annotation for pods that may be exploiting this bypass
• Audit existing pod specifications for envFrom fields that reference secrets outside the permitted service account scope
• Update to a patched Kubernetes version as soon as available for your distribution
• Implement additional admission controllers (OPA Gatekeeper, Kyverno) to enforce secret access policies as a defense-in-depth measure

Patch Information

Kubernetes has addressed this vulnerability in newer releases. Administrators should upgrade to the latest patched versions for their respective release branches. Refer to the Kubernetes Security Announcement for specific version details. Fedora users should apply updates from the Fedora package announcements.

Workarounds

• Remove the kubernetes.io/enforce-mountable-secrets annotation from service accounts if the security requirement can be met through other mechanisms, as the feature is not functioning as intended
• Implement network policies and RBAC restrictions to limit which users can create pods in sensitive namespaces
• Use admission webhooks to manually validate that all secret references (including envFrom) comply with intended access policies
• Consider using namespace isolation to separate workloads that require access to different sets of secrets

# Check for pods using envFrom with secretRef in a namespace
kubectl get pods -n <namespace> -o json | jq '.items[] | select(.spec.containers[].envFrom[].secretRef != null) | .metadata.name'

# List service accounts with enforce-mountable-secrets annotation
kubectl get serviceaccounts -A -o json | jq '.items[] | select(.metadata.annotations["kubernetes.io/enforce-mountable-secrets"] == "true") | {namespace: .metadata.namespace, name: .metadata.name}'