Oxeye Finds Bad Spotify Backstage JavaScript Vulnerability
How bad? Is a Common Vulnerability Scoring System (CVSS) score of 10.0 bad enough for you?
These days with security holes appearing fast and furious it takes a truly exceptional security bug to catch my eye. However, cloud native security company Oxeye‘s discovery of a 10.0 CVSS vulnerability, (CVE-2022-36067) in a Spotify Backstage third-party modulus flashes like a burst of sunlight on a gray, cloudy day.
In case you’ve forgotten, a 10 has a potentially huge impact, and it’s a critical bug. In other words: “Fix it. Fix it now.”
Backstage In Use
This isn’t just a worry for Spotify users and programmers. Backstage unifies many infrastructure tools and services in a development environment also used by American Airlines, Netflix, Splunk, Fidelity Investments, Epic Games, and many, many others. Backstage is also used to hold integration details in such systems as Prometheus, Jira, ElasticSearch, and others — including, of course, quite possibly your projects.
Key Weakness
Backstage’s key weakness was found in its software templates. Each template is defined by a YAML file that resembles a Kubernetes resource. It contains the fields that define how components should act. The data provided to the message parameter is a template rendered by Mozilla Nunjucks. This works with JavaScript-based applications. Its basic idea comes from Jinja2, the Python template engine.
So far, so good. Oxeye, however, noticed that Nunjacks could be manipulated to run shell commands by using user-controlled templates. To lock down potential trouble from these shell commands, Backstage began using the vm2 JavaScript sandbox library.
But it turns out, there’s a way to escape from vm2. Once out, an attacker can run a remote code execution (RCE) on the host. As always, this is bad news.
But the next question was, “Could this exploit work within Backstage?” The answer: “Yes, yes, it could.”
Out of the Sandbox
By using the template to force Nunjacks to run SecureTemplater.render function twice, an attack could break out of the sandbox. That done, an attacker can create an object outside the sandbox, such as an executable arbitrary system command. That done, it’s too late to block the attacker because they’re inside and off to cause mischief.
OK, that’s bad. But there was worse to come. It turns out that when you deploy Backstage by default, it has no authentication mechanism. That’s asking for trouble. And, sure enough, Oxeye researchers found that “some of the public Backstage servers accessible to the internet did not require any authentication.”
Whoops.
Adding insult to injury, if you did add authentication, without additional work, it only enforced authentication on the client side. A request coming in from the backend API was not verified for authentication or for authorization.
Can we say “Whoops” again? Why, yes, we can.
The Fix
To fix the immediate problem, you should upgrade vm2 version 3.9.11. Well, what are you waiting for? Go and patch!
Oxeye also warns, however, there’s a bigger problem here. We assume sandboxes are safe. I mean, that is the name of their game. But, as this episode shows, that’s not always a safe assumption.
Oxeye recommends that if you must use a sandbox, you separate the logical, sensitive part of your application from the microservice that runs the sandbox code. That way, even if a hacker breaks out, their attack surface is limited to the isolated microservice.
The company also warns that you should “avoid using a sandbox that relies on a dynamic programming language such as JavaScript when possible. The dynamic nature of the language widens the attack surface for a potential attacker.” That’s a good point, and I recommend you take a close look at your sandboxes and see if there are better, safer alternatives for your projects.
