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.
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.”
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.
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.