Executive Summary

This vulnerability affects Fission, an open-source Kubernetes-native serverless framework. Prior to version 1.24.0, users with permissions to create or update environments (environments.fission.io) could bypass security restrictions and run privileged containers within the Fission function or builder namespaces. This was possible because certain container security settings were not properly validated or sanitized, allowing attackers to enable privileged mode, allow privilege escalation, or add dangerous capabilities like SYS_ADMIN.

As a result, these privileged containers run under a high-privilege service account, which can lead to container sandbox escape, unauthorized access to the host filesystem and network, and potentially compromise the entire Kubernetes node or cluster.

The issue was caused by gaps in the admission layer that only validated some container specifications and missed standalone container fields, combined with a merge layer that failed to sanitize security contexts in these containers. The vulnerability was fixed in version 1.24.0 by adding proper validation and sanitization.

Useful 0 Not Useful 0

Impact Analysis

If exploited, this vulnerability can have severe impacts including:

• Container sandbox escape, allowing attackers to break out of the container isolation.
• Unauthorized access to the host filesystem and network, potentially exposing sensitive data or internal services.
• Compromise of the Kubernetes node and potentially the entire cluster, leading to full control over the environment.
• Execution of privileged or dangerous capabilities within containers, increasing the attack surface.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability can be detected by checking for Environment CRD objects that have privileged or dangerous SecurityContext settings in their standalone container fields (spec.runtime.container and spec.builder.container). Specifically, look for containers with privileged: true, allowPrivilegeEscalation enabled, or dangerous capabilities like SYS_ADMIN.

Since the issue involves Kubernetes RBAC permissions and container security contexts, you can use kubectl commands to inspect Environment CRD objects and their container security contexts.

• kubectl get environments.fission.io -A -o json | jq '.items[] | {namespace: .metadata.namespace, name: .metadata.name, runtimeContainer: .spec.runtime.container.securityContext, builderContainer: .spec.builder.container.securityContext}'
• kubectl get pods -n <fission-function-or-builder-namespace> -o json | jq '.items[] | select(.spec.securityContext.privileged == true or .spec.securityContext.allowPrivilegeEscalation == true or (.spec.containers[].securityContext.capabilities.add[]? == "SYS_ADMIN")) | {pod: .metadata.name, namespace: .metadata.namespace}'

Additionally, review RBAC permissions to identify users or service accounts with create/update access to environments.fission.io resources, as these permissions enable exploitation.

Useful 0 Not Useful 0

Mitigation Strategies

Immediate mitigation steps include restricting RBAC permissions for environments.fission.io create/update operations to trusted users only, preventing untrusted tenants from creating privileged containers.

Deploy admission controller policies that block or reject Environment CRD objects with privileged SecurityContext settings such as privileged: true, allowPrivilegeEscalation enabled, or dangerous capabilities like SYS_ADMIN.

Enforce restricted Pod Security Standards in the Fission function and builder namespaces to prevent privileged pod creation.

Upgrade Fission to version 1.24.0 or later, where the vulnerability is patched by adding validation and sanitization of container security contexts in the Environment CRD admission and merge layers.

Useful 0 Not Useful 0

Compliance Impact

The vulnerability allows a tenant with certain RBAC permissions to run privileged containers that can escape container sandboxes and gain host filesystem and network access, potentially compromising the entire node and cluster.

Such a compromise could lead to unauthorized access to sensitive data or disruption of services, which may violate security requirements in common standards and regulations like GDPR and HIPAA that mandate protection of data confidentiality, integrity, and availability.

Therefore, if exploited, this vulnerability could negatively impact compliance with these regulations by enabling attackers to bypass security controls and access or manipulate protected data or systems.

Useful 0 Not Useful 0