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

Threat actors expand abuse of Microsoft Visual Studio Code

jamf.com

Post reply on HN
Print view View original

181–190 of 306 posts

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#181

Post by juujian »

pmontra wrote: post #108

My first reaction has been: when we install some node modules, import them and eventually run them, we do grant local execution permissions to whatever the authors of those modules coded in their scripts, right? More or less every language already suffer from the same problem. Who vets the code inside a Ruby gem, a Python package, etc? Add your favorite language. However I did not know about tasks.json (I don't use V…

On Debian I actually get a surprising amount of packages from just the official repo. In Python or R, I could almost do a full analysis just with those packages. The smaller number of separately installed packages, I can at least do a superficial sanity check. An alternative model of doing things exists. Considering how infinitesimally small Debian is compared to Windows and MacOS, if we had more users, momentum, and volunteers, I have no doubt that I could do everything with well-tested packages only.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#182

Post by hn-acct »

OoooooooO wrote: post #151
echoangle wrote: post #141

Earlier quoted context omitted.

The message displayed when asking if you want to trust the directory is pretty clear about it. https://code.visualstudio.com/docs/editing/workspaces/worksp...

The message, at least for me, does not convey that merely opening may lead to code execution.

Other IDEs do this too btw

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#183

Post by bilekas »

trelane wrote: post #173
bilekas wrote: post #118

Earlier quoted context omitted.

This is so insane to me. Eclipse is... Fine for Java in the sense Visual Studio is for dotnet. But man can they both be slow. Use case depending sometimes you just need a quick editor, thats why sublime had and probably still has a huge userbase, its fast startup and flexibility. Vim, emacs and derivatives of it are the same story. I can't imagine ever opening up eclipse to edit a zig/go/js file or project. It's too…

Emacs is a full IDE, not just a quick one-off editor. Its power comes from having everything scriptable from the ground up. Contrast this with the modern Extension concept, where there is a hard line between the editor's code and any changes you might want to make to its behavior. I think vim is probably similar, but I've not gotten into it that much.

Exactly, and infact vim is very simular, neovim in my case extensible through lua scripts as an example. It's as light or feature packed as I like.

Contrast that to Eclipse and Visual Studio (not vsCode) and it's clear why the larger IDE's are falling out of favour.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#184

Post by gosub100 »

morcus wrote: post #35
Alupis wrote: post #22

Earlier quoted context omitted.

How much ram did you have, and when was this? I remember being extremely happy with Eclipse on an 8GB machine - this was back in the jvm7 days. Heck, I did jvm6 development with Eclipse on Windows XP with 4GB of ram and was content. Eclipse gets a lot of automatic hate - I believe mostly since a lot of people first use it in university and struggled with their first real IDE. For years and years I had people telling…

> Eclipse gets a lot of automatic hate - I believe mostly since a lot of people first use it in university and struggled with their first real IDE. More like Eclipse struggled on the kind of hardware that people could afford as a student. My main memories of Eclipse (15 years ago at this point) are waiting forever for it to start up, though it was pretty adequate after that.

I remember the first thing you had to do with eclipse was increase the memory limit so the obese hog called JVM could have barely enough room to wiggle around.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#185

Post by gosub100 »

rovr138 wrote: post #81
DrewADesign wrote: post #40

Earlier quoted context omitted.

Right, but it’s essentially a fancy text editing environment. It should never have needed anything but barebones hardware.

> essentially a fancy text editing environment No, it’s an IDE first. Not a text editor that’s extensible. It has a lot of features built-in, pre-enabled, and configured out of the box. Yes, it can edit text. But it can do a lot more.

And it clearly violated the "only pay for what you use" philosophy. Like driving a bulldozer to get a soda.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#186

Post by __jonas »

andy_ppp wrote: post #129
mjdv wrote: post #121

Earlier quoted context omitted.

Until this post it wasn't clear to me that just opening and trusting a directory can cause code to be run without taking any other explicit actions that seem like they might involve running code, like running tests. My bad, but still!

What is the stated reasoning for arbitrary code execution as a feature? Seems pretty mad to me.

Here are some examples:

- ESLint, the most commonly used linter in the JavaScript ecosystem uses a JavaScript file for configuration (eslint.config.mjs), so if you open a JS project and want your editor to show you warnings from the linter, an extension needs to run that JS

- In Elixir, project configuration is written in code (mix.exs), so if you open an Elixir project and want the language server to provide you with hints (errors, warnings and such), the language server needs to execute that code to get the project configuration. More generally it will probably want to expand macros in the project, which is also code execution.

- For many languages in general, in order to analyze code, editor extensions need to build the project, and this often results in code execution (like through macros or build scripts like build.rs, which I believe rust-analyzer executes)

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#187

Post by Nathanba »

echoangle wrote: post #141
mjdv wrote: post #121

Earlier quoted context omitted.

Until this post it wasn't clear to me that just opening and trusting a directory can cause code to be run without taking any other explicit actions that seem like they might involve running code, like running tests. My bad, but still!

The message displayed when asking if you want to trust the directory is pretty clear about it. https://code.visualstudio.com/docs/editing/workspaces/worksp...

It's worded really badly, so vscode is the thing that provides the dangerous features? No problem, I know and trust vscode. What the message should be warning about is that the folder may contain dangerous code or configuration values that can execute upon opening due to vscode features that are enabled by default. That sounds worse for them but that would be honest.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#188

Post by elzbardico »

iberator wrote: post #64
josephg wrote: post #50

Earlier quoted context omitted.

It was 2010. Our default work machines had 16gb of ram. Eclipse ran, but it was tight. Especially while debugging. Some developers also apparently liked to open a second eclipse instance for some reason. You'd go OOM pulling stunts like that. They upgraded all of us to 32gb. 32gb doesn't sound like a lot of ram now, but in 2010 it seemed pretty wild to me. Especially for just running an IDE. In eclipse's defence, we…

16gb. Ram in 2010?! That's like top 10%, not standard. Even now computers are shipping with 16/32gb ram

At this time laptops still could have memory upgrades, and memory was pretty cheap compared to today. The first thing I did when I bought a new laptop was buying two 8GB SoDIMMs, it was way cheaper than ordering the upgrade from factory.

The thing is, memory in personal computer have plateaued for quite some time. 16GB was not uncommon in 2010. Things are not like the crazy 90s and early 2000s where PC configuration become obsolete in less than two years.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#189

Post by [deleted] »

jasode wrote: post #172
mjdv wrote: post #121

Earlier quoted context omitted.

Until this post it wasn't clear to me that just opening and trusting a directory can cause code to be run without taking any other explicit actions that seem like they might involve running code, like running tests. My bad, but still!

reply to multiple comments : mjdv : > it wasn't clear to me that just opening and trusting a directory andy_ppp : >obviously I wasn’t explicit enough in explaining I’m talking about code execution simply by opening a directory. Understandably, there's a disconnect in the mental model of what "opening a folder" can mean in VSCode. In 99% of other software, folders and directories are purely navigation and/or organizat…

[deleted]

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#190

Post by elzbardico »

ReptileMan wrote: post #65
josephg wrote: post #50

Earlier quoted context omitted.

It was 2010. Our default work machines had 16gb of ram. Eclipse ran, but it was tight. Especially while debugging. Some developers also apparently liked to open a second eclipse instance for some reason. You'd go OOM pulling stunts like that. They upgraded all of us to 32gb. 32gb doesn't sound like a lot of ram now, but in 2010 it seemed pretty wild to me. Especially for just running an IDE. In eclipse's defence, we…

>They upgraded all of us to 32gb. 32gb doesn't sound like a lot of ram now, but in 2010 it seemed pretty wild to me. Especially for just running an IDE. With the current prices it is still wild mate.

Funny thing, memory was cheaper, and machines were upgradeable. People used to buy low memory machines and upgrade them with after market memory to avoid paying DELL or Apple's memory upgrade tax.
Post reply on HN