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

181–190 of 191 posts

Re: Malicious VSCode extensions with more than 45k installs

#181

Post by thenerdhead »

pdimitar wrote: post #174
thenerdhead wrote: post #92

Earlier quoted context omitted.

Before you go down this rabbit hole, consider that many extensions are slight forks of others. There isn't always malicious intent. Just people who try to extend the extensions and publish them without knowing otherwise. For example go look at any popular "Hello world" type of extension and you'll see many results of extensions in this definition of "name squatting". i.e. https://marketplace.visualstudio.com/search?t…

Non-malicious forks would choose a completely different name and mention the original in their README. Name squatting relies on people making a typo and installing your stuff. That cannot be innocent, come on now. Your link also does not prove anything except that people naively make extensions with the same name that feels cute or easily discoverable to them. I see no name squatting in that list, not in the top 10-2…

> Name squatting relies on people making a typo and installing your stuff. That cannot be innocent, come on now.

You are thinking of typosquatting. And my example shows people can publish extensions squatting on the same extension name as established ones while also changing other metadata to impersonate or spoof popular ones and confuse users quickly looking to install the extension.

Re: Malicious VSCode extensions with more than 45k installs

#182

Post by hombre_fatal »

andrewmcwatters wrote: post #172
hombre_fatal wrote: post #143

Earlier quoted context omitted.

It’s a problem with security across computing in general, not just JS. For example, what are these languages and runtimes you have in mind that solve this issue with app plugins if VS Code were using them instead?

In other languages, it's possible to set environments where code run from that environment have restricted access to explicitly defined globals. You can do this to create things like plugin systems, etc, where you know by specification you never want a context to have access to say, making HTTP requests.

Out of curiosity, which languages?

Re: Malicious VSCode extensions with more than 45k installs

#183

Post by eptcyka »

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…

Cool, where can regular users get a setup like this that just works?

Re: Malicious VSCode extensions with more than 45k installs

#184

Post by sillystuff »

eptcyka wrote: post #183
sillystuff wrote: post #159

Earlier quoted context omitted.

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…

Cool, where can regular users get a setup like this that just works?

Nowhere?

You can get weaker jails, that are more likely to get in your way, on Linux and other platforms that "just work-ish" though [1].

Default jails on Linux with Firejail really is just install the application and run a single command, to jail everything it knows about. Or just create symlinks manually to be more selective. Not a high bar.

Having the ability to customize means not having to change the way I do things to conform to the whims of some random company. Jails that "just work", but do not allow customization are jailing the user too.

[1] You will need to adjust the way you work to the way the jails are setup by default. Some things you may want to do will not work at all, or not in the way you want them to. Many things will not be as extensively jailed as you might like. Applies to any of, Android, iOS, Firejail, etc., using defaults.

Re: Malicious VSCode extensions with more than 45k installs

#185

Post by sillystuff »

TheRealDunkirk wrote: post #168
sillystuff wrote: post #159

Earlier quoted context omitted.

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.

I used SELinux and AppArmor at work, and AppArmor for my own stuff. I found SELinux to be pretty unpleasant, but AppArmor rulesets / overrides not so bad. Definitely agree that there is a lot of room for improvement[1], but the tools exist, and if a person cares enough, can jail apps at least as securely as on any other platform.

[1] Other warts are not having syscall groups like openBSD pledge, so you have to track down new syscalls in each new kernel version to restrict using deny policies (which are more flexible than using explicit allow policies). And, linux capabilities are a mess that really deserves a do-over. You can get root with any of, at least, 6 capabilities. And, so much stuff is crammed into CAP_SYS_ADMIN and CAP_NET_ADMIN, that you effectively lose any granularity in selectively allowing privileged activities.

Re: Malicious VSCode extensions with more than 45k installs

#186

Post by rollcat »

medo-bear wrote: post #179
rollcat wrote: post #178

Earlier quoted context omitted.

> What it might do, however, is give you unparalleled power to inspect your environment [...] The "read the source" argument. It doesn't scale. I don't have 17 lifetimes to study a single release of every bit of software I run. I really do appreciate Emacs for the introspection capabilities, but it's not a solution to the trust chain issue.

It scales to "don't run untrusted code if you are concerned about security"

> don't run untrusted code

The entire point of this thread is how a chain of trust should be maintained. "Don't run untrusted code" is skipping from the question straight to a hypothetical world where an answer has already been established.

"How to live long" - "don't die".

Re: Malicious VSCode extensions with more than 45k installs

#187

Post by permo-w »

pdimitar wrote: post #173
permo-w wrote: post #88

Earlier quoted context omitted.

Darcula Dark could easily be what it says it is, which is an innocent take on the VS Code’s default Darcula theme. I’d be willing to bet there are innocent VSCode extensions with Darcula in the title, and I don’t think that’s unreasonable or traitorous of any kind of intent

Still doesn't excuse telemetry for something as trivial though. Innocent == 100% offline and benefiting society. If they need telemetry for a color theme then they are not innocent.

I’m not defending the package, just pointing out that sharing a namespace doesn’t instantly imply guilt

Re: Malicious VSCode extensions with more than 45k installs

#188

Post by andrewmcwatters »

hombre_fatal wrote: post #182
andrewmcwatters wrote: post #172

Earlier quoted context omitted.

In other languages, it's possible to set environments where code run from that environment have restricted access to explicitly defined globals. You can do this to create things like plugin systems, etc, where you know by specification you never want a context to have access to say, making HTTP requests.

Out of curiosity, which languages?

Lua comes to mind first, with `setenv`, other languages have similar functionality. I believe this can be done with C#, too.

Re: Malicious VSCode extensions with more than 45k installs

#189

Post by megous »

moonchrome wrote: post #123
megous wrote: post #64

Earlier quoted context omitted.

Oh, yeah. That's how I have to treat large orgs as a contractor. :) And trouble start almost immediately, because they apply PoLP only to you... First thing with a new client is usually some form of a VPN access. Even with open protocols, it's challenging to secure a VPN access. Eg. by default running openvpn with a random config provided by a third party allows the third party to push any network setup they want rem…

I use a VM for each client. I host it on my desktop and then when I need to work from a laptop I just SSH into the VM. This way I never "forget to turn off the client VPN" and similar BS, and my client files don't get mixed up, etc.

That works for a client or two. I'm already at ~20 and there will eventually be hundreds. Managing all that via random VMs and VPN solutions (I've had some require some smartphone app, and one time codes + pins just to connect to VPN) would just be sheer craziness if everyone was allowed their own VPN solution and network setup.

Re: Malicious VSCode extensions with more than 45k installs

#190

Post by megous »

pfg_ wrote: post #144
megous wrote: post #52

Earlier quoted context omitted.

> every program you install gets full access to the system It gets your user's privileges when you run it. It's up to you how you run your programs. Also there's no "default Linux configuration". There are many distributions, and they have different defaults and approaches.

my user's privileges contain my ssh keys, my passwords database, my personal files, ...

But that's your choice. I have multiple "users", and only one of them has access to ssh keys, etc. Users I use for less trusted apps just have write access to their mostly empty home dir filled with some dotfiles "whatever" app created by itself.

You can firewall by process UIDs/GIDs too, and I use that to allow the user access only to the internet and not to localhost or home network, or only to localhost, etc.

Post reply on HN