Remote Memory Exposure in openwhisk
Summary
GHSA-53mj-mc38-q894: Remote Memory Exposure in openwhisk. Affects openwhisk versions < 3.3.1. Fixed in 3.3.1. How to fix ↓
Check if this vulnerability affects your application
Upload a manifest or SBOM and we'll show whether you're affected, plus every other risky package in the same scan.
No signup required · Results in about 60 seconds
Background
Openwhisk is an open-source serverless computing platform that allows developers to build and run applications without the need to manage infrastructure. It provides a scalable and event-driven architecture for executing code in response to various triggers. Openwhisk supports multiple programming languages and offers a rich set of features for developing serverless applications. However, versions of openwhisk before 3.3.1 are vulnerable to remote memory exposure.
Vulnerability Detail
The vulnerability in openwhisk arises when a number is passed to the api_key parameter. In affected versions, openwhisk allocates an uninitialized buffer and sends it over the network in the Authorization header (base64-encoded). This can lead to remote memory exposure, potentially allowing an attacker to access sensitive information from the server's memory. An attacker could exploit this vulnerability to obtain sensitive data, such as API keys or user credentials, compromising the security and integrity of the system.
How To Fix
Minimum fixed version
3.3.1
This is the first release that contains the fix.
npm install openwhisk@3.3.1Tip — Not sure which version your app runs? Vulert can match this fix to it. Scan free →
Workaround
If updating to the latest version is not immediately feasible, a temporary workaround is to avoid passing a number to the api_key parameter. Instead, ensure that only valid alphanumeric strings are used as the API key. This can be achieved by validating and sanitizing user input before passing it to openwhisk. Here's an example of how to sanitize the input in JavaScript:
var sanitizedApiKey = api_key.toString().replace(/[^a-zA-Z0-9]/g, '');
Conclusion
The vulnerability in openwhisk that allows remote memory exposure can have serious security implications. It is crucial to update to version 3.3.1 or later to mitigate this vulnerability. If immediate updating is not possible, ensure that user input is properly validated and sanitized to prevent passing numbers to the api_key parameter. For further support and assistance in vulnerability remediation, please contact DevNack.com.
See every vulnerability recorded for openwhisk →
FAQ
Openwhisk is an open-source serverless computing platform that allows developers to build and run applications without managing infrastructure. It provides a scalable and event-driven architecture for executing code in response to triggers.
Remote memory exposure refers to a vulnerability where an attacker can access sensitive information from a server's memory remotely. In the case of openwhisk, passing a number to the api_key parameter can trigger the vulnerability and expose uninitialized memory.
This vulnerability can allow an attacker to obtain sensitive information from the server's memory, such as API keys or user credentials. With this information, the attacker can compromise the security and integrity of the system, potentially leading to unauthorized access or data breaches.
To fix this vulnerability, it is recommended to update to version 3.3.1 or later of openwhisk. This version includes a patch that addresses the remote memory exposure issue. Updating to the latest version ensures that the uninitialized buffer is properly handled and eliminates the risk of memory exposure.
If updating to the latest version is not immediately feasible, a temporary workaround is to avoid passing a number to the api_key parameter. Instead, ensure that only valid alphanumeric strings are used as the API key. This can be achieved by validating and sanitizing user input before passing it to openwhisk.
