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

161–170 of 191 posts

Re: Malicious VSCode extensions with more than 45k installs

#161

Post by mkeedlinger »

andrewmcwatters wrote: post #125

There's some capabilities-based security talk going on here, but the current state of the art in JavaScript makes absolutely no sense to me. It's nonsensical on its face. Right now, you grant caps through Deno to the whole executable script--so dependencies left and right that don't need caps get them. So, what's the point? It's literally worthless. It does nothing to stop capabilities abuse. The same thing could hav…

I wonder how this would look elsewhere as things like WASM for extensions becomes more popular. How would you model capabilities in Rust? How would that not apply to the whole results binary?

Re: Malicious VSCode extensions with more than 45k installs

#162

Post by gcr »

robertlagrant wrote: post #95
samatman wrote: post #62

Earlier quoted context omitted.

> No. Theming addons should not even be able to ask for those privileges. That's not the principle of least privilege, that's a user rule, and it isn't necessarily a good one. I can imagine, for example, a theming add-on which queries a weather API and picks colors based on that, perhaps displaying a nice weather bar in the status line. Such a theme would need to be granted this privilege, which should ideally be res…

Agree, although what would be really useful is if the capability listed exactly what data will be queried from VSCode and sent to the remote endpoint.

Something like a declared list of DNS domains the extension wants to access?

Re: Malicious VSCode extensions with more than 45k installs

#163

Post by hoosieree »

fwlr wrote: post #78
explaininjs wrote: post #48

Earlier quoted context omitted.

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.

For over 20 years now, professional woodworkers have had SawStops, devices that literally use an explosive charge to ram a block of aluminum into the blade of a table saw when it detects that the blade is touching something that might be a human body part. These are $50+ devices that destroy themselves on use (and often destroy the $50+ blade they’re used on), they have a high false positive rate, and yet they’re sti…

But if saw stops are mandatory, how the heck am I supposed to cut hotdogs?

Re: Malicious VSCode extensions with more than 45k installs

#164

Post by anthk »

rollcat wrote: post #86
anthk wrote: post #71

Earlier quoted context omitted.

So it's Emacs, but we want features and not to be locked. Don't run propietary crap, trust Elisp repo like ELPA and NonGNU and you will be mostly safe.

Isn't MELPA just serving the latest git master of whatever it happens to be at the time package-refresh-contents was called? With MELPA stable likewise just serving the latest tag? That doesn't spell trust.

MELPA is not ELPA.

Re: Malicious VSCode extensions with more than 45k installs

#165

Post by TingPing »

RMPR wrote: post #154
eviks wrote: post #82

Earlier quoted context omitted.

Many distros with many approaches, yet not a single one with a convenient security feature that comment is mentioning So it's not "up to me" if the good choice is not practical

Fedora (and I think all the RHEL family) comes with SE Linux by default. Although I'm not that familiar with it (I tend to disable it more often than not) it seems to me like it's addressing precisely that.

selinux isn't used in any meaningful way for desktop software.

The actual solution in that space is Flatpak.

Re: Malicious VSCode extensions with more than 45k installs

#166

Post by Jorengarenar »

maccard wrote: post #15
throwaway290 wrote: post #10

Earlier quoted context omitted.

I always give source code a glance, unless it's by a sufficiently prominent and reputable maintainer.

Do you check _their_ dependencies though? And do you check every file?

Only handful of Vim plugins have dependencies and even then you need to install them explicitly

Re: Malicious VSCode extensions with more than 45k installs

#167

Post by TingPing »

barbariangrunge wrote: post #110
codedokode wrote: post #34

Earlier quoted context omitted.

Yes! Sadly, today nobody seem to care about the principle of least privileges. Take Linux as an example: every program you install gets full access to the system, and gets thousands of privileges it doesn't need. If your PDF reader is vulnerable, it will have both access to your SSH keys and to the Internet to upload them (and if you block Internet access for a PDF reader, it still can send the data by connecting to…

Question: do snaps or similar tech in the distros help with this?

Yes Snap and Flatpak directly help solve this problem.

Re: Malicious VSCode extensions with more than 45k installs

#168

Post by TheRealDunkirk »

sillystuff wrote: post #159
eptcyka wrote: post #129

Earlier quoted context omitted.

Do you execute your SSH agent as a different user/group from the one you use for your PDF reader? Does Firefox only get to read and write to ~/.config, ~/.cache and ~/Downloads? The capabilities are there for the people who want to hot glue some elaborate contraptions together, but there is no good UX or DX for doing this in a composable manner for end user consumption.

The tools are there, if you care to use them. A combination of very restrictive globals.local and .local files added to Firejail + custom apparmor rules allows me to jail applications as well or likely better than is possible on any other platform. Other tools are available that accomplish the same, if either or both of these is not to your liking (firejail has improved greatly with recent versions, if your opinion w…

Indeed, SELinux and AppArmor are the tools here. I had a lot of trouble with them when they first came out, and just left them out of the loop. I had forgotten them since moving to Mac's about 8 years ago.

Re: Malicious VSCode extensions with more than 45k installs

#169

Post by arp242 »

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

In the context of an editor, this can be bypassed by writing this kind of code to the project, which will be run when the developer runs the project, runs tests, or in some languages even when the project is compiled.

A theme probably doesn't need access to the project files, but many extensions do. This is much harder to solve than in e.g. Android.

Re: Malicious VSCode extensions with more than 45k installs

#170

Post by paulddraper »

codedokode wrote: post #34
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.…

Yes! Sadly, today nobody seem to care about the principle of least privileges. Take Linux as an example: every program you install gets full access to the system, and gets thousands of privileges it doesn't need. If your PDF reader is vulnerable, it will have both access to your SSH keys and to the Internet to upload them (and if you block Internet access for a PDF reader, it still can send the data by connecting to…

> Sadly, today nobody seem to care about the principle of least privileges.

People care.

But not enough to go through AppArmor/SELinux hell.

It's a lot of work.

Post reply on HN