VS Code Extention Security: How Do I Plug This Hole?
I had a developer ask me a straightforward question:
How do I ensure I don’t install malicious extensions on VS Code?
I suppose it’s a bit like NPM(or any other registry). You have publishers that push out these nifty add-ons that make your work easier in some way, but it’s supposed to be gate-kept by the strong arms of Microsoft, right?
I didn’t know for sure, so I offered some standard advice. It was roughly the same thing I’d offer if someone asked if they were trying to avoid installing a bad NPM package.
After giving it some thought, without forcing developers to use a preset of approved extensions (most would probably start looking for work elsewhere) I’d offer the following advice:
Use Verified Extensions Only. Stick to only using extensions published and maintained by trusted developers/organizations; extensions that have the “Verified Publisher” badge.
Review Extension Ratings and Reviews. Before installing, check the ratings and reviews. Be wary of extensions with low ratings, few downloads, or reviews mentioning suspicious behaviour.
Check Extension Permissions. Extensions that request excessive permissions might be risky if they don’t need them to work (like access to file system, network, etc.).
Regularly Update Extensions. Ensure that your extensions are up-to-date, as updates often include security fixes. VS Code typically prompts you to update extensions. You can manually check for updates in the Extensions view.
Disable or Uninstall Unused Extensions. Disable or uninstall extensions you don’t actively use to reduce the attack surface and minimize potential vulnerabilities.
Use Workspace Trust. This feature allows you to trust the code in your workspace selectively. When you open a new folder, you can choose whether you trust the workspace. Extensions that run code are disabled in untrusted workspaces (like tasks, debugging, etc.).
Review the Source Code. If you’re technically inclined, you can review the source code of an extension (assuming it’s open-sourced).
Enable Telemetry and Security Alerts. Allow VS Code to send telemetry data which helps Microsoft identify and block malicious extensions. VS Code may show alerts if it detects extensions behaving suspiciously.
Use an Antivirus or Security Tool. Ensure you have an updated antivirus or a security tool that can detect and alert you about potential malicious activities.
Credit to Ilay Goldman and Yakir Kadkoda in their article walking through a Masquerading attack gave me a good sense of things to look out for.
However, disturbingly, they also pointed out an attacker can easily get around verification.
“ … in the Marketplace the verified blue check mark merely means that whoever the publisher is has proven the ownership of a domain. That means any domain. In reality, a publisher could buy any domain and register it to get that verified check mark.”
Additionally, forging a glut of downloads can be easily accomplished, adding a layer of unearned social proof. See their proof of concept for the shocking results
So let’s not put full stock into the first two bits of advice on my list above…
Next, let’s look at extension permissions and updating/uninstalling extensions.
Interestingly, Microsoft can issue a hit on offending extensions. I’m assuming it immediately forces the extension to uninstall the next time your VS Code connects to the marketplace, but I couldn’t verify if that’s how it works or if there’s a delay.
Some questions are bubbling up now. This ties into some of the settings around extension updates. For example, in settings.json:
{
"extensions.autoUpdate": false,
"extensions.autoCheckUpdates": false
}These settings opt out of automatic extension updates. Does this circumvent the kill list or delay it? I don’t know for sure.
If it does, could an attacker effectively nudge users to open their settings to make this update? I could see the preview page for an extension making a well-social-engineered ask to dupe users to do this:
I just changed the install steps, but the rest can be spoofed as mentioned above. Pretty spooky hey?
Maybe the kill shot that Microsoft can deliver is highly effective, making my concern highly overblown, but just in case it isn’t, what now?
I’d have to rely on the bottom of my original list as the final defenders.
Using Workspace Trust to reduce the blast radius I’d also encourage using a list of recommended extensions using the .vscode/extensions.json file:
{
"recommendations": [
"ms-python.python",
"dbaeumer.vscode-eslint"
]
}Users opening the workspace will be prompted to install the recommended extensions, but it doesn’t force developers into a set workflow, allowing for individual personalization. It can also open the door to getting more code reviews on potential new extensions people want to recommend to their team.
I’d also ensure that point was extremely well communicated to the development team — it is just a recommendation! I’m not here to shackle anyone down but to reduce our risks overall.
Which leads me to my final point.
You can see that most of my recommendations have some workaround/flaw/limitation individually. This is going to be the case with any effective security strategy. The more of those recommendations you implement, the lower your risk.
Good security is always a layered approach, if the first layer is compromised you should have a few more walls behind it. Don’t rely on one or two protections, use many layers!
If you found this valuable, please follow the blog, where I’ll continue to post on security topics and more! Stay safe out there!
