Malicious VSCode extensions infect Windows with cryptominers

[jakeroxs@sh.itjust.works]

Might be one thing AI tools will be super useful for, if it's possible to teach it what types of code are potentially malicious and able to automatically flag it for review AT LEAST.

[cupcakezealot@lemmy.blahaj.zone]

im glad his hand got chopped off

[cupcakezealot@lemmy.blahaj.zone]

shocker. an electron app that's terrible and full of malware.

[passenger@lemm.ee]

Just that? An open source HTML minifier probably bundled with a miner.

[ziltoid1991@lemmy.world]

Kate >>> VSCode

[msage@programming.dev]

Can your Linux do that?

.

.

.

.

.

.

.

.

Yes, of couse it can, all of that and even more!

[zygo_histo_morpheus@programming.dev]

Don't think it has anything to do with electron. VSCode is just the largest editor that people install extensions for, so it's what makes the most sense to write malware for. If vim was more popular, I'm sure there would be more crypto mining extensions for that (I wonder how many there are? Surely more than zero?)

[benjhm@sopuli.xyz]

It seems so far Zed is cautious, providing api only for specific extensions - i.e. language servers and gui themes.

add a line ... right before you run it

I run stuff from the command line using a trusted build tool (Mill, in scala), or via a local server (where js is sandboxed).
But indeed, a tricky language server or AI tool (I don't use yet) might inject code where I don't inspect before running it.
That's a risk even with java-based IDEs - java has security permissions, not in js (vscode) or rust (zed), but are they applied...?
As for audits, a problem with vscode is the marketplace got too big, so many extensions, many lookalikes, nobody can check them all...

[shnizmuffin@lemmy.inbutts.lol]

Minification isn't the same as obfuscation, though. The only way I can think to obfuscate HTML would be to replace every element with a custom element.

[passenger@lemm.ee]

Well, one could make up all kinds of tactics. Especially with the help of css styles inside the document? For example: add random crap, make it invisible. Make the real content hard to see or find in the document. Why though? I don't know! Now I am kind of curious to know what it did, if anything.

[brian@programming.dev]

well the language server plugins all run a binary language server out of sandbox so zed doesn't really do anything safer in particular there either. no ide has solutions, solutions don't really exist right now. it's not a problem of features of the language as much as it is features developers expect in extensions. I suppose there is a hypothetical "the extension wants to make this change to this file, approve" type flow like AI tools have now, but that sounds unpleasant to use. it still doesn't get around things like language servers being designed to run as standalone processes out of sandbox.

by audits I meant you individually go and read all the code of all the extensions you use. of course that's impossible too, but that was my point

[piccolo@sh.itjust.works]

It also helps its as easy as clicking a button to install an extension... and i wonder how many even bother checks the source of the extension?

[spacemanspiffy@lemmy.world]

Let this be a lesson. We should never, ever, use software.

[abnorc@lemm.ee]

Software is the leading cause of all computer viruses.

[killabeezio@lemm.ee]

Oh Hi Mark

[lemminary@lemmy.world]

All people who use software will fucking die, smh.

[driving_crooner@lemmy.eco.br]

It's also kinda "trusted" in corporations. The one I work for have github blocked for some reason, but any user cam install VS code and extensions by itself.

[kissaki@programming.dev]

Minification is a form of obfuscation. It makes it (much) less readable.

Of course you could run a formatter over it. But that's already an additional step you have to do. By the same reasoning you could run a deobfuscator over more obfuscated code.

[kissaki@programming.dev]

The collaborative sharing nature of these platforms is a big advantage. (Not just VS Code Marketplace. We have this with all extension and lib and program package managers.)

Current approaches revolve around

• reporting
• manual review
• automated review (checks) for flagging or removal
• secured naming spaces

The problem with the latter is that it is often not necessarily proof of trustworthyness, only that the namespace is owned by the same entity in its entirety.

In my opinion, improvements could be made through

• better indication of publisher identity (verified legal entities like companies, or of persona, or owned domain)
• better indication of publisher trustworthiness (how did they establish themselves as trustworthy; long running contributions in the specific space or in general, long standing online persona, vs "random person", etc)
• more prominent license and source code linking - it should be easy to access the source code to review it
• some platforms implement their own build infrastructure to ensure the source code represents the published package

Maybe there could be some more coordinated efforts of review and approval. Like, if the publisher has a trustworthiness indication, and the package has labeled advocators with their own trustworthiness indicated, you could make a better immediate assessment.

On the more technical side, before the platform, a more restrictive and specific permission system. Like browser extensions ask for permissions on install and/or for specific functionality could be implemented for app extensions and lib packages too. Platform requirements could require minimal defaults and optional things being implemented as optional rather than "ask for everything by default".

[kissaki@programming.dev]

Who is Kate?

Kate the editor? Or is there an IDE called Kate?