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

171–180 of 191 posts

Re: Malicious VSCode extensions with more than 45k installs

#171

Post by paulddraper »

skc wrote: post #107
explaininjs wrote: post #9

Article disingenuously wraps a couple extensions that seem to be “actually” malicious (secret stealing), with one that has a lot of installs and is “HN-malicious” (collects telemetry) for a striking headline. That said, malicious code in VS Code extensions is a problem. I wonder if a GPT could be helpful here. The existing internal systems for detecting malicious code seem lacking.

"HN-malicious" Hehe. We could probably come up with a dozen similar HN specific adjectives.

"HN-stupid"

Anything known to be wrong with 20/20 hindsight.

Re: Malicious VSCode extensions with more than 45k installs

#172

Post by andrewmcwatters »

hombre_fatal wrote: post #143
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…

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.

Re: Malicious VSCode extensions with more than 45k installs

#173

Post by pdimitar »

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

Earlier quoted context omitted.

Name squatting always betrays malicious intent. No benefit of the doubt is owed to anyone practicing it.

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.

Re: Malicious VSCode extensions with more than 45k installs

#174

Post by pdimitar »

thenerdhead wrote: post #92
pdimitar wrote: post #77

Earlier quoted context omitted.

Name squatting always betrays malicious intent. No benefit of the doubt is owed to anyone practicing it.

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-20 anyway.

Re: Malicious VSCode extensions with more than 45k installs

#175

Post by eviks »

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.

It can't address that when it's disabled, and since it's not a good tool of addressing the issue, it stays disabled

Re: Malicious VSCode extensions with more than 45k installs

#176

Post by newaccount74 »

ianzakalwe wrote: post #130

Actually malicious extension only had 250 downloads, 45k installs extension was sending telemetry only. It’s a very misleading title collapsing two separate incidents into one for the sake of dramatization. This article also highlighted that automated tools used by VS team are pretty good at catching most of similar issues.

Tracking your host name is not telemetry, it's definitely spyware.

Re: Malicious VSCode extensions with more than 45k installs

#177

Post by scotty79 »

newaccount74 wrote: post #176
ianzakalwe wrote: post #130

Actually malicious extension only had 250 downloads, 45k installs extension was sending telemetry only. It’s a very misleading title collapsing two separate incidents into one for the sake of dramatization. This article also highlighted that automated tools used by VS team are pretty good at catching most of similar issues.

Tracking your host name is not telemetry, it's definitely spyware.

Still, it's not nearly on the same level as exfiltrating secrets.

Re: Malicious VSCode extensions with more than 45k installs

#178

Post by rollcat »

medo-bear wrote: post #112
rollcat wrote: post #86

Earlier quoted context omitted.

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.

Using Emacs is not going to help you to avoid supply chain attacks per se. What it might do, however, is give you unparalleled power to inspect your environment - calls and source. If you run untrusted code you are exposed, and thats that. Development tools should assume that you, a programmer, know what you are programming. Emacs and lisp is focused on providing power, not security. These often do not go hand in han…

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

Re: Malicious VSCode extensions with more than 45k installs

#179

Post by medo-bear »

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

Earlier quoted context omitted.

Using Emacs is not going to help you to avoid supply chain attacks per se. What it might do, however, is give you unparalleled power to inspect your environment - calls and source. If you run untrusted code you are exposed, and thats that. Development tools should assume that you, a programmer, know what you are programming. Emacs and lisp is focused on providing power, not security. These often do not go hand in han…

> 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"

Re: Malicious VSCode extensions with more than 45k installs

#180

Post by cywick »

newaccount74 wrote: post #176
ianzakalwe wrote: post #130

Actually malicious extension only had 250 downloads, 45k installs extension was sending telemetry only. It’s a very misleading title collapsing two separate incidents into one for the sake of dramatization. This article also highlighted that automated tools used by VS team are pretty good at catching most of similar issues.

Tracking your host name is not telemetry, it's definitely spyware.

Exactly. Typically, exfiltrating this kind of information is only the first step. Once enough high value targets are caught in this net, the actual malware is deployed.
Post reply on HN