Visual Studio Code extensions are much less secure than browser extensions or even npm packages
A trope old enough to date back to the dawn of software dev is when one vendor shits on another one in order to promote a new product of theirs.
A recent iteration of this is the following series of blog posts highlighting some of the many issues with Microsoft’s Visual Studio Code, all leading up to the announcement of a product that promises to (but won’t) fix the extension security problem.
(VirusTotal didn’t make a dent in the malware problem. This won’t either.)
Even though the motivation for the series is quite meh, the problems it observes are entirely accurate.
- “1/6 | How We Hacked Multi-Billion Dollar Companies in 30 Minutes Using a Fake VSCode Extension”. “30 minutes is all it takes to bypass the most sophisticated security environments.”
- “2/6 | Exposing Malicious Extensions: Shocking Statistics from the VS Code Marketplace”. “Extensions in Visual Studio Code are not sandboxed, they can access anything inside the IDE and can execute anything on the host machine without the developer getting any feedback.”
- “3/6 | A Letter to Microsoft: Uncovering Design Flaws of Visual Studio Code Extensions”. “Yes, as you guessed, there is no verification mechanism that you actually own the Github repo, nor is there any sort of verification that the uploaded code is actually code that is on the Github repo.”
This is both and old problem and a long-exploited one. According to an unrelated article from last year that highlighted many of the same problems:
We’ve also discovered that some extensions may have already been taking advantage to exploit this attack vector.
The problems with Visual Studio Code are numerous (there’s a reason why I don’t use it any more). It has a ton of UX issues, but the poor security is a much more serious issue, although one that is practically standard for Microsoft products. (Seriously, they are much worse than other vendors when it comes to security.)
Some of the highlight problems from the above blog posts:
- Extensions don’t have much in terms of permission management. An extension can do pretty much anything it wants, load what it wants, read and write what it wants, and run whatever it likes.
- They automatically update, which makes a bait-and-switch tactic easy, where an attacker first publishes a legitimate extension but later updates it to include malware.
- Publisher accounts are both commonly unverified and too easy to verify. All you need is a verified domain.
- The information is just taken from a GitHub project and there apparently isn’t any verification that the project matches what’s in the extension, so an attacker could have an open source GitHub project while actually shipping different code with the extension.
- You can install-bomb your way to increasing the install count of your extension. There’s no attempt to verify the data that is being used in the extension store to indicate popularity or trustworthiness.
The above issues mean that VS Code extensions are a bigger security issue than npm packages, for example. Unlike packages, extensions update and run in the background, usually throughout the developers entire work day.
Visual Studio Code isn’t the only extensible IDE to have these issues, but it is by far the largest. That means that the benefit to the malware maker is disproportionately bigger.
The upside of managing to deliver a seemingly innocuous but compromising extension is enormous.
So big, in fact, that it’d be foolish to think it isn’t already happening.