Executive Summary

This vulnerability exists in Fission, an open-source Kubernetes-native serverless framework, in versions up to 1.23.0. The issue arises because builder pods were created with the ServiceAccountName set to fission-builder and did not explicitly disable the automatic mounting of the service-account token. As a result, the kubelet automatically mounted the fission-builder ServiceAccount token into every container in the pod, including user-supplied builder containers.

This means that any code running inside these user-controlled builder containers inherited the fission-builder identity, which has namespace-wide permissions to read Secrets and ConfigMaps. An attacker who has permissions to create or update Environment Custom Resource Definitions (CRDs) in a namespace monitored by the builder manager could exploit this vulnerability to read all Secrets and ConfigMaps in that namespace by leveraging the auto-mounted token.

The vulnerability was fixed in version 1.24.0 by disabling the auto-mounting of the ServiceAccount token at the pod level and ensuring it remains disabled even if a user-supplied pod specification tries to re-enable it. Additionally, the token is restricted to a projected volume accessible only to the fetcher sidecar, which maintains necessary cluster API access for legitimate build operations while preventing unauthorized access.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability can lead to unauthorized access to sensitive information within a Kubernetes namespace. Specifically, an attacker who can run code in the user-supplied builder container and has permissions to create or update Environment CRDs could exploit the auto-mounted fission-builder ServiceAccount token to read all Secrets and ConfigMaps in the builder namespace.

Since Secrets and ConfigMaps often contain sensitive configuration data, credentials, or other confidential information, this unauthorized access could lead to information disclosure, potentially compromising the security of applications and infrastructure running in that namespace.

The CVSS score of 4.9 reflects a moderate severity, with a high confidentiality impact but requiring high privileges to exploit.

Useful 0 Not Useful 0

Detection Guidance

To detect this vulnerability, you should check if your Fission builder pods are running versions prior to 1.24.0 and if they have the ServiceAccountName set to fission-builder with the service account token auto-mounted.

You can inspect the pods in the builder namespace to see if the service account token is mounted inside the user-supplied builder containers.

• Run the command to list builder pods and check their service account and volume mounts: kubectl get pods -n <builder-namespace> -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}{.spec.serviceAccountName}{"\n"}{.spec.volumes[*].name}{"\n"}{end}'
• Check if the service account token is mounted inside the pod containers: kubectl describe pod <pod-name> -n <builder-namespace> | grep -A5 'Volumes'
• Verify the Fission version running: fission version

Useful 0 Not Useful 0

Mitigation Strategies

The primary mitigation step is to upgrade Fission to version 1.24.0 or later, where the vulnerability has been fixed.

This update disables the automatic mounting of the fission-builder ServiceAccount token in builder pods, preventing unauthorized access to Secrets and ConfigMaps.

If upgrading immediately is not possible, consider manually disabling the auto-mounting of the service account token in builder pods by setting AutomountServiceAccountToken to false in the pod specifications.

Additionally, review and restrict permissions on Environment CRDs and monitor for any suspicious activity related to builder pods.

Useful 0 Not Useful 0

Compliance Impact

This vulnerability allows unauthorized access to Secrets and ConfigMaps within the builder namespace by malicious user-supplied builder containers. Since Secrets often contain sensitive information such as credentials, tokens, or configuration data, unauthorized access could lead to data exposure.

Such unauthorized access to sensitive data can impact compliance with common standards and regulations like GDPR and HIPAA, which require strict controls over access to sensitive and personal data to ensure confidentiality and prevent data breaches.

By exposing sensitive information through the auto-mounted ServiceAccount token, this vulnerability could potentially lead to violations of these regulations if exploited, as it undermines the principle of least privilege and secure handling of sensitive data.

Useful 0 Not Useful 0