Executive Summary

The vulnerability in Fission, a Kubernetes-native serverless framework, involves the Fission router exposing an internal route `/fission-function/<ns>/<name>` on its public listener (port 8888) prior to version 1.23.0.

This internal route was intended for internal triggers but was mistakenly registered on the public listener shared with user-defined HTTPTriggers. As a result, any external caller who could reach the router could invoke any function by guessing its name and namespace, bypassing the usual HTTPTrigger restrictions such as host, path, method, and method-allow-list.

This allowed unauthorized invocation of functions, including internal or sample functions, and enabled enumeration of function names and cross-tenant access in multi-tenant deployments.

The issue was fixed in version 1.23.0 by splitting the router into two listeners: a public listener for user HTTP triggers and a new internal listener protected by HMAC authentication and NetworkPolicy restrictions for function invocations.

Useful 0 Not Useful 0

Compliance Impact

The vulnerability allows unauthorized invocation of any function in the Fission serverless framework by bypassing HTTPTrigger restrictions, which can lead to unauthorized access to sensitive data or internal functions.

Such unauthorized access and potential data exposure can negatively impact compliance with common standards and regulations like GDPR and HIPAA, which require strict controls on data confidentiality, integrity, and access.

The vulnerability enables attackers to bypass access controls and potentially access or manipulate sensitive information, violating principles of least privilege and data protection mandated by these regulations.

The patch introduced in version 1.23.0, including splitting the router into public and internal listeners with HMAC authentication and NetworkPolicy restrictions, helps restore compliance by enforcing proper access controls and preventing unauthorized function invocations.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability can have severe impacts including unauthorized invocation of any function deployed in the Fission framework without proper access controls.

• Bypassing HTTPTrigger restrictions means attackers can invoke internal or sensitive functions that were not meant to be publicly accessible.
• Attackers can enumerate function names and namespaces, potentially gaining insight into the internal structure and operations of your deployment.
• In multi-tenant environments, this can lead to cross-tenant access, violating tenant isolation.
• The vulnerability has a critical CVSS score of 9.8, indicating high impact on confidentiality, integrity, and availability without requiring privileges or user interaction.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability can be detected by checking if the Fission router's public listener (port 8888) exposes the internal route /fission-function/<ns>/<name> without authentication, allowing unauthorized invocation of functions.

You can attempt to invoke functions by sending HTTP requests to the router on port 8888 targeting the /fission-function/ path with guessed function names and namespaces to see if they respond without authentication.

• Use curl or similar tools to send requests to the router, for example: curl http://<router-ip>:8888/fission-function/<namespace>/<function-name>
• Monitor network traffic for unauthorized access attempts to /fission-function/ endpoints on port 8888.
• Check router configuration and logs for exposure of internal routes on the public listener.

Useful 0 Not Useful 0

Mitigation Strategies

The primary mitigation is to upgrade the Fission router to version 1.23.0 or later, where the vulnerability is fixed by splitting the router into two listeners: a public listener on port 8888 for user HTTP triggers and a new internal listener on port 8889 for function invocations, protected by HMAC authentication and NetworkPolicy restrictions.

Until upgrading, you should apply NetworkPolicies to block external access to the /fission-function/ paths on the router's public listener and avoid exposing the router directly to untrusted networks.

Additionally, consider implementing authentication mechanisms and restricting network access to the router to trusted sources only.

Useful 0 Not Useful 0