Executive Summary

This vulnerability exists in Fission, an open-source Kubernetes-native serverless framework. Before version 1.24.0, Fission's Environment Custom Resource Definition (CRD) allowed users to specify pod specifications for runtime and builder pods through certain fields without proper filtering or security checks.

Specifically, the merge logic combined user-supplied pod specifications with Kubernetes pod specs without filtering sensitive fields such as hostNetwork, hostPID, hostIPC, container privileged mode, and serviceAccountName. The validation function did not perform security checks on these fields.

As a result, users with create or update permissions on environments.fission.io could create privileged pods with host network and process ID access in Fission namespaces. Since the namespaces lacked pod-security labels, Kubernetes Pod Security Admission did not block these pods.

This allowed attackers to escalate privileges from limited RBAC permissions to gaining host filesystem and network access, potentially compromising the entire node and the Kubernetes cluster.

The issue was fixed in version 1.24.0 by adding admission denylist checks, sanitizing dangerous pod specification fields, and extending validation to update operations.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability can have severe impacts including privilege escalation and cluster compromise.

• An attacker with limited permissions can create privileged pods that have host network and process ID access.
• This can lead to gaining access to the host filesystem and network.
• Attackers can escalate from namespace-level permissions to full node compromise.
• Potentially, the entire Kubernetes cluster can be taken over by the attacker.

Overall, this vulnerability poses a critical security risk with a CVSS score of 9.9, indicating high impact on confidentiality, integrity, and availability.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability can be detected by inspecting the Environment Custom Resource Definitions (CRDs) in your Fission deployment, specifically looking at the spec.runtime.podSpec and spec.builder.podSpec fields for unsafe configurations.

You should check if any pods have been created with privileged settings, hostNetwork, hostPID, hostIPC enabled, or with elevated serviceAccountName values that could indicate exploitation attempts.

• Use kubectl to list Environment CRDs and inspect podSpec fields: kubectl get environments.fission.io -o yaml
• Check pods in fission-function and fission-builder namespaces for privileged or host network settings: kubectl get pods -n fission-function -o jsonpath='{range .items[*]}{.metadata.name}{": "}{.spec.hostNetwork}{", "}{.spec.hostPID}{", "}{.spec.hostIPC}{", "}{.spec.containers[*].securityContext.privileged}{"\n"}{end}'
• Audit Kubernetes audit logs for creation or update of Environment CRDs with suspicious podSpec fields.

Useful 0 Not Useful 0

Mitigation Strategies

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

This update includes an admission denylist that blocks dangerous pod specifications and sanitizes the podSpec fields during the merge process.

Additionally, ensure that Kubernetes Pod Security Admission is enabled and properly configured on the fission-function and fission-builder namespaces to prevent creation of privileged or host network pods.

Review and restrict RBAC permissions to limit who can create or update environments.fission.io resources.

Useful 0 Not Useful 0

Compliance Impact

This vulnerability allows low-privilege users to escalate privileges and potentially compromise Kubernetes nodes and clusters by exploiting unfiltered pod specification fields. Such a compromise could lead to unauthorized access to sensitive data and systems.

Given the potential for unauthorized access and escalation, this vulnerability could negatively impact compliance with standards and regulations like GDPR and HIPAA, which require strict controls over data access and system security to protect personal and sensitive information.

By enabling attackers to gain host filesystem and network access, the vulnerability increases the risk of data breaches and unauthorized data processing, which are critical concerns under these regulations.

Useful 0 Not Useful 0