I'm confused why they think this is malware as opposed to just a miner optimized to run on Lambda. It even says, "we don't know how this gets deployed".
Presumably someone just deploys it so they can do mining taking advantage of Lambda's free tier.
It looks like it could be a binary intended to be snuck in with third party package dependencies and such that you might unintentionally execute within your lambda runtime. It's one thing doing mining at a slow trickle within the free tier of a single account, and another thing altogether when potentially millions of lambda functions in the wild are mining for you.
But agreed, it's not necessarily functionally different from any other crypto-mining malware hidden in public repos, save for the focus on runtime. Presumably Lambda provides a standardized enough runtime for reliable execution.
AWS lambda has a bunch of python specific optimisations that make python the best candidate for lambdas, and solve cold-start and other issues you'd normally face with python. (Azure has similar for C#).
I wonder if calling it python enables some of these, while allowing you to actually implement it in something efficient, like C.
Lambda runs a custom compiled interpreter with different flags set than most distros. In this case they don't compile python with optimizations on, which is weird, and they link an old version of SQLite.
I guess the different flags makes sense - the VMs Lambda runs on run Amazon Linux as far as I understand. But turning off optimisations does seem strange.
I'd guess they'd run in firecracker VMs (a technology they open sourced), targeting faster starts. And perhaps turning off the compile time flags also results in a faster-starting binary, which is the more important metric for serverless, maybe at the expense of slower code/longer runtime, excepting that runtimes are on average quite short anyway.
> AWS lambda has a bunch of python specific optimisations that make python the best candidate for lambdas (...)
I don't believe there is any truth to this statement.
The general guidelines for AWS lambda is that a) if you seek performance then Go is the way to go, b) for everything else nodejs (i.e., JavaScript/typescript) is by far the best runtime, specially given lambda's single-threaded nature and nodejs's support for concurrency.
All other options are only relevant if you have very specific non-technical constraints, such as wanting to reuse code (JDK) or just leveraging whatever language your team already uses somewhere else.
Lambda isn't single threaded. You get a core for every gig of ram that you allocate up to 16GB. Multiprocessing has been supported for a long time for at least the past 3 years I think.
> Lambda isn't single threaded. You get a core for every gig of ram that you allocate up to 16GB.
That's not exactly true.
As per AWS, with AWS Lambda you only get a second core if you provision more than 1769MB of RAM.
The number of cores can grow up to a max of 6 with provisions of over 10GB of RAM albeit AWS does not specify how that's supposed to be mapped.
There are some empirical and highly unofficial tests on AWS Lambdas that indicate that more than 1 vCPU are allocated with provisions of over 800MB of RAM, but each of those vCPUs are capped at 50% of a CPU core.
The key factor here, and what makes AWS Lambda's nodejs runtime the absolute best runtime and the de facto standard for lambdas, is that nodejs's single-threaded event loop already buys you the ability to execute code concurrently without having to rake up a large bill and resort to arcane tricks to reign that under control.
I'd add that AWS Lambda's blog post on parallel processing in Python starts off by making it clear that nodejs is the way to go.
Curious to see how this would be deployed in the wild. A sneaky way would be to add this as an extension to existing Lambdas - it could run in parallel any time such a Lambda is invoked, and continue even after an initial response until the timeout for the function is reached.
They state that “the managed runtime environment reduces the attack surface compared to a more traditional server environment”, but is that true? Isn’t it just that the attack surface that you are responsible for is reduced? I could see all the lambda “magic” (i.e., reducing cold start times) actually adding to the runtime attack surface.
17 comments
[ 4.9 ms ] story [ 47.9 ms ] threadPresumably someone just deploys it so they can do mining taking advantage of Lambda's free tier.
But agreed, it's not necessarily functionally different from any other crypto-mining malware hidden in public repos, save for the focus on runtime. Presumably Lambda provides a standardized enough runtime for reliable execution.
I wonder if calling it python enables some of these, while allowing you to actually implement it in something efficient, like C.
I don't believe there is any truth to this statement.
The general guidelines for AWS lambda is that a) if you seek performance then Go is the way to go, b) for everything else nodejs (i.e., JavaScript/typescript) is by far the best runtime, specially given lambda's single-threaded nature and nodejs's support for concurrency.
All other options are only relevant if you have very specific non-technical constraints, such as wanting to reuse code (JDK) or just leveraging whatever language your team already uses somewhere else.
That's not exactly true.
As per AWS, with AWS Lambda you only get a second core if you provision more than 1769MB of RAM.
The number of cores can grow up to a max of 6 with provisions of over 10GB of RAM albeit AWS does not specify how that's supposed to be mapped.
There are some empirical and highly unofficial tests on AWS Lambdas that indicate that more than 1 vCPU are allocated with provisions of over 800MB of RAM, but each of those vCPUs are capped at 50% of a CPU core.
The key factor here, and what makes AWS Lambda's nodejs runtime the absolute best runtime and the de facto standard for lambdas, is that nodejs's single-threaded event loop already buys you the ability to execute code concurrently without having to rake up a large bill and resort to arcane tricks to reign that under control.
I'd add that AWS Lambda's blog post on parallel processing in Python starts off by making it clear that nodejs is the way to go.
https://aws.amazon.com/blogs/compute/parallel-processing-in-...