Fission Container Executor PodSpec Injection – Privilege Escalation via Unvalidated Tenant Input

Vulnerability Description

This vulnerability exploits a missing input validation + insecure merge pattern in Fission's container executor. The root cause is twofold: (1) FunctionSpec.Validate() only checks for the presence of a PodSpec but does not inspect its contents for dangerous fields, and (2) MergePodSpec() unconditionally forwards security-sensitive fields (hostPID, hostNetwork, hostIPC, privileged mode, host-path volumes, and service account overrides) into the resulting Deployment. A tenant holding only functions.fission.io/create RBAC permission can craft a Function CRD with a malicious PodSpec that mounts the host filesystem and shares host namespaces. Because the executor runs under a high-privilege service account with deployments/create permissions, it inadvertently creates the attacker's Deployment with the specified pod-security configuration, turning application-level function creation into effective cluster control.

PoC Significance

This proof-of-concept demonstrates a direct privilege-escalation vector that bypasses Kubernetes' multi-tenancy controls. The PoC proves that an attacker requires only a low-privilege RBAC role (function developer) to achieve administrative-equivalent capabilities (node escape, host filesystem access, and arbitrary container privilege escalation). The attack is highly reliable because it does not depend on race conditions or runtime behavior; it is a deterministic payload-injection flaw. Preconditions are minimal: a Fission cluster with the container executor enabled and a tenant account with functions/create permissions (a common baseline in multi-tenant environments).

Detection Guidance

Log Indicators:

• Monitor functioncreated or functionupdated audit events followed immediately by deploymentcreated events with identical pod-security parameters.
• Search audit logs for Deployments created with hostPID: true, hostNetwork: true, hostIPC: true, or privileged: true in the pod spec, especially when the creator is a non-admin service account (the executor).
• Flag Functions where spec.podSpec contains host-related fields that differ from the executor's baseline template.
• Watch for service account name overrides in Function specs that grant higher privileges than the creator's own RBAC allows.

Monitoring Rules:

• Alert on any functions.fission.io/create event that results in a Deployment with host namespace sharing or privileged containers.
• Correlate Function creation events with subsequent node-level access logs (kubelet API calls, host filesystem mounts detected via container runtime events).

Mitigation Steps

1. Immediate Patch: Upgrade Fission to a patched version that validates PodSpec content against a security policy (whitelist allowed fields).
2. Input Validation Fix: Implement strict allowlisting in FunctionSpec.Validate() to reject any PodSpec containing hostPID, hostNetwork, hostIPC, privileged mode, host-path volume definitions, or service account overrides.
3. Merge Security: Modify MergePodSpec() to strip or reject security-sensitive fields before merging tenant input into the executor's template.
4. RBAC Hardening: Restrict the executor's service account to deployments/create only in the function namespace, and audit which namespaces it has permissions in.
5. Pod Security Policy / Standards: Enforce a restrictive PSP or Kubernetes Pod Security Standards (PSS) at the enforcer namespace level that forbids hostPID, hostNetwork, and privileged containers.
6. Temporary Workaround: Disable the container executor if not required, or restrict functions.fission.io/create permissions to trusted users only.

Risk Assessment

Likelihood of Exploitation: High. This vulnerability requires only standard tenant permissions in a multi-tenant Fission cluster and is trivial to exploit once discovered. The attack surface is broad: any tenant function developer can attempt it. No special network access, timing, or external resources are needed.

Threat Actor Interest: Very high. Cloud-native environments running shared Fission clusters (e.g., SaaS platforms, managed Kubernetes services, internal multi-tenant platforms) are attractive targets. Ransomware operators and cloud-focused APTs will prioritize RBAC-bypass exploits like this to maintain persistence and lateral movement across tenant boundaries.

In-the-Wild Risk: Moderate-to-high risk of exploitation by insiders or compromised developer accounts. External attackers would need legitimate function-developer credentials, but social engineering, phishing, or credential harvesting could grant this access. The vulnerability's deterministic nature and minimal prerequisites make it a high-confidence target for adversary playbooks.