I agree to TechTarget’s Terms of Use, Privacy Policy, and the transfer of my information to the United States for processing to provide me with relevant information as described in our Privacy Policy.

Please check the box if you want to proceed.

I agree to my information being processed by TechTarget and its Partners to contact me via phone, email, or other means regarding information relevant to my professional interests. I may unsubscribe at any time.

Please check the box if you want to proceed.

By submitting my Email address I confirm that I have read and accepted the Terms of Use and Declaration of Consent.

The vulnerability was found in Apache OpenWhisk, which IBM engineers created and upon which they built IBM Cloud Functions -- a functions-as-a-service programming platform to develop lightweight code that executes on demand. Apache and IBM quickly patched the vulnerability, which was discovered and brought to their attention by PureSec, before it got out into the wild, said Ory Segal, CTO and co-founder of PureSec, based in Tel Aviv, Israel.

According to PureSec's tests, an intruder could exploit the vulnerability to insert malicious code with the same permissions as the serverless function it replaced. Specifically, a remote attacker could overwrite the source code of a vulnerable function executed in a runtime container and influence subsequent executions of the same function in the same container. The attacker could then extract confidential customer data, such as passwords or credit card numbers; modify or delete data; mine cryptocurrencies; and more, Segal said.

Other OpenWhisk-based serverless platforms, such as Adobe I/O, were not impacted by the vulnerability because a provider may opt not to use the runtime images provided by Apache OpenWhisk, said Rodric Rabbah, co-creator of OpenWhisk and recent co-founder of CASM, a stealth startup focused on serverless computing. OpenWhisk accepts user functions and then dynamically injects that code into Docker container images; a vendor can provide its own images, for example to provide a runtime that contains libraries that are important for their organization.*

IBM acknowledged its gratitude to PureSec, but Big Blue characterized the vulnerability as "very minor," and it was quickly addressed within a week. The quick response also highlighted the benefit to building and operating technology in the open source community, which can rapidly make improvements and correct vulnerabilities.

Memo to devs: Secure your serverless code

This was an example of how a serverless function -- or any other app running as a server, in a VM or container -- needs to be secured by the developer, just as if they were writing any code that runs as an exposed endpoint API on the web.
Rodric Rabbahco-creator of Apache OpenWhisk

Vulnerabilities exist in open source serverless computing, just as they do in any open source software, said Krishnan Subramanian, an analyst at Rishidot Research in Seattle. "This one is in user space. So, this becomes a critical problem if the user code is also vulnerable," he said.

Serverless functions such as OpenWhisk, as well as AWS Lambda and Google Cloud Functions, execute user functions or user-provided code. The weakness reported with this vulnerability requires an attacker to compromise the _user_function code and replace it with new code or just run new code in the background. The attack then only compromises a single container in which the function runs.

OpenWhisk already assumes any user function is malicious, so it isolates user functions from each other and, of course, isolates the system itself. The reported issue did not compromise OpenWhisk's overall protection, because the effect is isolated to vulnerable user code and whatever that user's function handled, Rabbah said.

A list of Common Vulnerabilities and Exposures related to OpenWhisk is now available to users, including those who have commercial products based on the technology. And the Apache OpenWhisk team has audited all the runtimes and normalized the error-handling to provide greater and uniform observability, Rabbah said. This adds a layer of protection for the user, but really does not absolve them of the responsibility to secure their code, he noted.

"This was an example of how a serverless function -- or any other app running as a server, in a VM or container -- needs to be secured by the developer, just as if they were writing any code that runs as an exposed endpoint API on the web," Rabbah said.

Join the conversation

1 comment

Register

I agree to TechTarget’s Terms of Use, Privacy Policy, and the transfer of my information to the United States for processing to provide me with relevant information as described in our Privacy Policy.

Please check the box if you want to proceed.

I agree to my information being processed by TechTarget and its Partners to contact me via phone, email, or other means regarding information relevant to my professional interests. I may unsubscribe at any time.