TL;DR We’ve found a vulnerability in FunctionShield, a cloud security library, that allows bypassing its tightest restrictions completely.
All technical details can be found in the "Process" section.
Cloud computing platforms are highly common these days. Fortunately, the times when companies used to make silly mistakes like leaving the Amazon S3 bucket open are gone. Yet, the cloud ecosphere remains counter-intuitive for many users, and they can and will make mistakes.
Take AWS Lambda, for example. On-demand execution of user code in a serverless ecosystem, what could go wrong? When user code is involved, there is plenty of ways to shoot yourself in the foot. This problem is kind of obvious, and there are some products developed to keep your cloud application safe.
One of them is FunctionShield.
Important note: FunctionShield is no longer maintained by the developers. So, it looks like there won’t be any security patches – that’s a very solid reason for not using it because you can’t rely on it anymore.
It’s a free library, and it seems to be secure, so why not use it? Check the statistics. There are no stats for pip or pip3, only for npm:
https://npm-stat.com/charts.html?package=%40puresec%2Ffunction-shield&from=2019-12-01&to=2019-12-31
So, it’s still about 8800 downloads for npm, December 2019.
Still, FunctionShield is used in some middleware software for AWS Lambda:
https://github.com/middyjs/middy
Tech sites and blogs recommend using it, and some cloud security lists include it:
https://geekflare.com/serverless-application-security/
https://www.jeremydaly.com/serverless-security-with-functionshield/
https://anir0y.live/class/blog/securityaudit-aws/
And here’s some guy saying that their company uses it in production (please don’t):
https://blog.innomizetech.com/2019/11/19/07-best-practices-when-using-aws-ssm-parameter-store/
You get the point – people out there are still using FunctionShield.
So, let’s see how this library works.
How FunctionShield works
FunctionShield is a compiled library and can be used in applications on NodeJS, Python, or Java. It’s specialized for working in AWS (AWS Lambda) and Google Cloud Functions environments.
FunctionShield has five options; four of them are policies that restrict code execution to prevent potentially malicious activities, and one policy is a switch that disables the sending of telemetrics to the developers’ server.
Now, let’s look at the four restrictive policies:
- Disable read and write to tmp folder
- Disable spawning child processes
- Disable network interaction
- Disable reading of the handler’s source code file (in our case, it’s handler.py).
Each options has three modes:
Block – the library interrupts every attempt to use a certain type of actions;
Alert – sends alerts when triggered;
Allow – does nothing.
We tested the Python version of FunctionShield on AWS Lambda.
Vulnerability: TL;DR
The FunctionShield library stores its permission rules in a binary file in the tmp folder on the system. If an attacker is able to rewrite it, FunctionShield will think that spawning child processes is allowed. From this moment on, the attacker is able to create child processes that are not covered by the FunctionShield’s rules set, so they are not affected by any restrictions.
For full technical coverage of this vulnerability, go to the second part of this article – the research process.
Solution:
Do not rely on FunctionShield!
Currently, it is useless. Since FunctionShield is now deprecated, we don’t think that will change in the future. All you need in a modern cloud environment is to figure out your role system and configure it right. Yes, sometimes it’s hard to do, but if you can’t set up your cloud role system according to your situation – you’re sitting on a time bomb, and no magic library will save you.
Author: md5(d22b44ecf71c2c2686c58e817a8f03e0)
