Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Malicious VSCode extensions with more than 45k installs

blog.checkpoint.com

Post reply on HN
Print view View original

41–50 of 191 posts

Re: Malicious VSCode extensions with more than 45k installs

#41

Post by explaininjs »

capableweb wrote: post #33
tjoff wrote: post #28

Earlier quoted context omitted.

Not really, if you are aware of that and have been actively been opting out of vscode telemetry it is downright malicious of addons to do it behind your back anyway.

If a product forces you to opt-out from telemetry, it makes sense that extensions would approach the problem the same way and force you to opt-out from each extension's telemetry. I'm not saying that's good, just that it makes sense that whatever ecosystem/community spawns from your product, they adopt the same methodology as the main product uses.

It makes more sense that the extension would check the configured telemetry enablement state and use that. Perhaps provide an extension-specific override, but certainly don’t default to anything besides the global value.

This is what happens if you use the first party telemetry module msft provides, but obviously not if you’re just sending random http requests.

Re: Malicious VSCode extensions with more than 45k installs

#42

Post by samwillis »

Silhouette wrote: post #32
imoverclocked wrote: post #20

Earlier quoted context omitted.

Sure, but the business model for the entity providing that sucks. Practically infinite amounts of possible exploits and extremely finite resources to detect them. Either that or you are back to where you started with a web of trust.

I agree that would be a tough business model. Even for a relatively small package set like VS Code plugins there must be many thousands of releases to check every year and the potential market of paying customers for the tool is limited. Maybe it could work if some of the tech giants sponsored it? For the wider problem of depending on external packages and managers like pip or npm I don't see how anyone could realist…

> Maybe it could work if some of the tech giants sponsored it

its not about them sponsoring it, that frames it wrong. They news to use it, they have security budgets in the tens of millions, they will already be doing some auditing of their own. A vendor can provide that service to the wider market.

Re: Malicious VSCode extensions with more than 45k installs

#43

Post by carlmr »

Gigachad wrote: post #24
fwlr wrote: post #19

Capabilities-based security prevents these supply chain attacks! (Even though in this case most of the downloads were of packages including unwanted telemetry and not something more dangerous.) “…And now if a [color theme] wants to read your data and send it to a server, it needs a filesystem capability and a network capability. It should be an obvious red flag if a [theming addon] were to ask for those dependencies.…

Yeah, android tried this initially with the permissions system. But literally every app requested every permission and it became completely useless. As a user, you have no way of meaningfully using this info.

I'd say VSCode is a bit different in who it's aimed at. Only because it doesn't work for a consumer product doesn't mean this wouldn't work for VSCode.

Also it might be good to be more specific. E.g. don't ask for all permissions at once, instead if the app starts talking to telemetry.endpoint.com it has to ask for these specific permissions at that point.

Then the user can see, hey this is requesting access to this particular server, that seems fishy, let's not proceed.

Re: Malicious VSCode extensions with more than 45k installs

#44

Post by capableweb »

carlmr wrote: post #36
tjoff wrote: post #28

Earlier quoted context omitted.

Not really, if you are aware of that and have been actively been opting out of vscode telemetry it is downright malicious of addons to do it behind your back anyway.

It would be good if VSCode asked you which permissions a plugin should have. E.g. a lot of plugins shouldn't be talking to the internet, writing to disk or similar in the first place. And if they do you should be able to whitelist what they're allowed to access.

There are generally two ways to go about to enable plugins in whatever you're building:

- Clear API boundaries that defines what you can do or not, with each API surface being obsessively guarded in terms of what it lets through. Usually leads to secure extensions but hard (if not impossible) to do things the API authors didn't foresee as it's locked down hard. Figma plugins use this approach.

- Give extensions raw access to the host platform, to do whatever they want. This is what VSCode and many others do, which comes with a lot of issues regarding security, but plugin authors can essentially do whatever they want.

The first approach requires a lot of careful consideration, development time and maintenance, while leading also to a somewhat locked down environment. It's more secure, but also limits the usefulness of some extensions.

Microsoft, in their usual lazy fashion, chose the latter approach, probably because it makes the most money sense. Why spend a lot of development time (and money) when you can do it faster and for less money? Some security holes won't lose you a ton of money, but spending N developers building a proper plugin API will for sure cost you a ton of money.

Re: Malicious VSCode extensions with more than 45k installs

#46

Post by joshuaissac »

Gigachad wrote: post #24
fwlr wrote: post #19

Capabilities-based security prevents these supply chain attacks! (Even though in this case most of the downloads were of packages including unwanted telemetry and not something more dangerous.) “…And now if a [color theme] wants to read your data and send it to a server, it needs a filesystem capability and a network capability. It should be an obvious red flag if a [theming addon] were to ask for those dependencies.…

Yeah, android tried this initially with the permissions system. But literally every app requested every permission and it became completely useless. As a user, you have no way of meaningfully using this info.

> android tried this initially with the permissions system. But literally every app requested every permission and it became completely useless.

Google could have fixed this by allowing the user to give the app mock permissions instead, e.g. empty or randomly-generated storage, fake camera device, randomly-generated contact list, etc. Third-party solutions that allow this have been around for about a decade, but they do not have the reach that Google does.

Re: Malicious VSCode extensions with more than 45k installs

#47

Post by blazespin »

maccard wrote: post #13

This article is a good example of how to write a misleading headline. They found 3 extensions, one of which has 45k downloads (because it name squats on a popular package), and another with 1000 installs. The 45k dowload extension (Darcula Dark) collects some data that I would define as telemetry, and the python-vscode extension which is clearly trying to hide what it's doing. Now, whether you define telemetry as mal…

uhm, it sends your hostname, detailed OS information, and by default, your publicly routable ip address (on the packet). That's pretty malicious.

I don't think the title was deceptive.

Re: Malicious VSCode extensions with more than 45k installs

#48

Post by explaininjs »

codedokode wrote: post #29

As I understand, VSCode extensions can run arbitrary shell commands and Microsoft didn't add any security measures (e.g. asking a user for confirmation). In this case it is only a matter of time, motivation and perseverance until all users who use extensions will get a back door. Of course this applies not only to VS Code, but to any other software which allows to install third-party extensions like browsers, Gimp, I…

Indeed. Professional woodworking equipment can also cut you, but that’s a risk we accept as we know their developers also care more about providing a tool that works and can be used responsibly by trained professionals. Yes we could insist everyone only hands us straight jackets in padded rooms, but I’m not sure that’d be a good thing.

Re: Malicious VSCode extensions with more than 45k installs

#49

Post by newaccount74 »

maccard wrote: post #13

This article is a good example of how to write a misleading headline. They found 3 extensions, one of which has 45k downloads (because it name squats on a popular package), and another with 1000 installs. The 45k dowload extension (Darcula Dark) collects some data that I would define as telemetry, and the python-vscode extension which is clearly trying to hide what it's doing. Now, whether you define telemetry as mal…

> collects some data that I would define as telemetry

Maybe the platform and os can be described as "telemetry", but logging the hostname definitely counts as stealing private data!

Apple by default uses the user's name as host name (eg. "John-Does-Macbook-Air.local"), so you could use this to determine if a specific person has installed your extension.

That is spyware, not telemetry.

The malicious extension could then, once it has determined a specific target user has installed the extension, ship a malicious update.

Re: Malicious VSCode extensions with more than 45k installs

#50

Post by ryanjshaw »

Gigachad wrote: post #24
fwlr wrote: post #19

Capabilities-based security prevents these supply chain attacks! (Even though in this case most of the downloads were of packages including unwanted telemetry and not something more dangerous.) “…And now if a [color theme] wants to read your data and send it to a server, it needs a filesystem capability and a network capability. It should be an obvious red flag if a [theming addon] were to ask for those dependencies.…

Yeah, android tried this initially with the permissions system. But literally every app requested every permission and it became completely useless. As a user, you have no way of meaningfully using this info.

Users here are experienced developers, so I think it's not such a big deal. In context, a theme should never need network or file storage access, so you could upfront block those for that type of extension. You can also have policies like "network access is okay but file system and network access together needs approval".
Post reply on HN