Switching out the Software Templates Sandbox
TL;DR: For the Backstage maintainers, ensuring that the project is highly secure for every adopter and end-user is one of our top priorities. With the recent vulnerabilities in the vm2
sandbox we have decided to move away from vm2
and use isolated-vm
instead, in order to ensure the security of the Backstage end-users.
A quick download on templating strings
When using Software Templates, we allow template authors to write advanced templating strings when composing actions together like the following:
- id: template
name: Fetch Skeleton + Template
action: fetch:template
input:
url: ./skeleton
copyWithoutRender:
- .github/workflows/*
values:
component_id: ${{ parameters.component_id }}
description: ${{ parameters.description }}
destination: ${{ parameters.repoUrl | parseRepoUrl }}
owner: ${{ parameters.owner }}
These parts that are wrapped with ${{ … }}
are evaluated by the Software Templates backend plugin.
The template strings provide a rich API that enables template authors to manipulate the parameters provided by users of the templates and to pass the parameters into both the built in filters and custom filters that template authors provided when configuring the plugin.
This templating language is called Nunjucks, which is based on Jinja2, both of which are popular templating engines.
Under the hood these templating strings compile into JavaScript. The Backstage Threat Model treats the code provided by the template language as untrusted, so adopters need a safe environment – a sandbox – to execute the JavaScript in.
Up until the latest Backstage release, that sandbox was vm2
. Now, the project is instead using isolated-vm
as the sandbox to execute this JavaScript in.
Why the change?
You might have seen over the last few months some advisories and CVEs that were found in the original vm2
sandbox that we were using.
Both the vm2
maintainers and the Backstage maintainers have been quick at releasing new versions of the sandbox and the Software Templates backend plugin, respectively, to protect their users.
We were recently made aware of another sandbox escape through our HackerOne BugBounty program, with a Proof of Concept using a Software Template.
The maintainers of the vm2
project have also been notified. We currently cannot find a simple solution to stop the latest escape. So, In the interest of moving quickly to protect the security of our end-users, we're moving away from that vm2
and moving towards isolated-vm
instead.
vm2
has been one of the most popular sandboxes to-date, and we want to thank the vm2
maintainers for the recent sandbox escape fixes and getting those shipped as fast as possible.
What does this mean for Backstage?
isolated-vm
uses a quite different implementation and security model compared to vm2
.
It is a native dependency and executes code in a v8
engine so-called isolate
instead. This means that by design, it does not have any access to neither the node runtime nor any frameworks on top of v8
, which is precisely what we want to ensure in our sandbox.
This method of sandboxing is much more secure than how the vm2
sandbox functions, and less prone to escapes.
While we can rest assured that this is a highly secure sandbox, the native dependency might mean there's a little more burden on adopters to install this dependency properly and have the right libraries set up. This native dependency must be built upon installation, on the exact architecture that it executes on.
For those who compile and run Backstage on stripped-down environments, you will want to ensure that you have the build basics present, e.g. build-essential
or similar corresponding to your operating system of choice.
The isolated-vm
repo has some further information about the build environment requirements.
With all that said, we think this tradeoff is worth the effort to ensure better security.
What do you need to do?
This change comes with the v1.15.0 release of Backstage that was released yesterday, so please make sure you are upgraded to the latest version of Backstage to keep your sandbox environments secure.
For more guidance on how to upgrade, check out the documentation for keeping Backstage updated.
If you have any further questions you can either reach out to us in the Community Discord, or in the office hours.