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

151–160 of 306 posts

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#151

Post by OoooooooO »

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

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

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#152

Post by rcxdude »

jhancock wrote: post #105

In VS Code settings search for "tasks" you will find "Task: Allow Automatic Tasks"...turn it off. Anything else that should be locked down?

Don't mark the folder as trusted when you open in VsCode. The number of other hooks that may exist is going to be hard to track down (especially because each addon may add their own).

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#153

Post by _sinelaw_ »

Is this 'task' feature really useful? I'd say applications like IDEs and text editors should not have automatic arbitrary execution of code in the first place. 'eval' should be blocked and extensions/plugins should have only very limited power to execute external logic (such as processes for LSP) or require allowlisting manually every process.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#154

Post by rcxdude »

jotaen wrote: post #143

Not a VSCode user, so a genuine question: what are practical use-cases in which you want VSCode to automatically execute a task only by opening a folder? Is it only for convenience so it already `npm i` or `npm start` without you having to do anything, or are there any other legitimate purposes beyond that?

Apart from this feature specifically, in general people would like their IDE to run language servers, set up build systems, and any number of other things which are likely to require some configuration which allows executing some code in the folder to work. VS code has a restricted mode to prevent this, which you need to accept a dialog to disable, but it also disables most of its features.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#155

Post by rcxdude »

duskdozer wrote: post #144
echoangle wrote: post #139

Earlier quoted context omitted.

https://code.visualstudio.com/docs/editing/workspaces/worksp... It is very clear, the first sentence it that it may automatically execute code.

>Code provides features that may automatically execute files... What features? What files? "may"? So will it actually happen or is it just "well it possibly could"? I've used it to open folders that I personally made and which don't have any tasks or files that get automatically executed, and yet the message pops up anyway. It's like having an antivirus program that unconditionally flags every file as "this file may…

Yeah, because there are a lot of mechanisms by which a folder may start to execute code when you open it outside of restricted mode. A large fraction of addons have something which could be used for this, for example. There isn't a general check that it can apply ahead of time for this.

(They could, with some breaking changes, maybe try to enforce a permissions system for the matrix of addons and folders, where it would ask for permission when an addon does actually try to run something, but this would result in a lot of permission requests for most repos)

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#156

Post by rcxdude »

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.

Really? "May automatically execute files" suggests to me that at least code could execute without me taking any further explicit action.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#157

Post by andy_ppp »

embedding-shape wrote: post #148
andy_ppp wrote: post #129

Earlier quoted context omitted.

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

Programming projects frequently feature scripts for building and packaging said projects, those have to be run somehow. Bundling running those into the editor seems like the mad part to me, but I've missed the whole VSCode train so probably something I'm missing.

The grand parent is talking about code execution can happen by just opening the directory, you’re imagining like I did (and the grandparent) that you have to run or execute something in VSC to get that to happen and I’m asking about what features could possibly require this to happen. Obviously running tests or a make file everyone understands clearly you’re executing other people’s code.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#158

Post by andy_ppp »

direwolf20 wrote: post #131
andy_ppp wrote: post #129

Earlier quoted context omitted.

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

Makefiles etc. Many types of projects use arbitrary setup and build commands or can load arbitrary plugins, and unlike VS which imposes its own project format, VSC tries to be compatible with everything that people already use. Git hooks are another one.

Please see the reply to the other comment, obviously I wasn’t explicit enough in explaining I’m talking about code execution simply by opening a directory.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#159

Post by rcxdude »

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.

When you open up a folder in VS code, addons can start to set up language servers to index the code in the folder. This usually involves invoking build systems to set those up.

(I think some people are fixating on the specific feature that's mentioned in the article. The reason this pop-up exists is that there are many ways that this code execution could happen. Disabling this one feature doesn't make it safe, and this feature if not present, could still be achieved by abusing other capabilities that exist in the vs code ecosystem)

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#160

Post by arzig »

andy_ppp wrote: post #157
embedding-shape wrote: post #148

Earlier quoted context omitted.

Programming projects frequently feature scripts for building and packaging said projects, those have to be run somehow. Bundling running those into the editor seems like the mad part to me, but I've missed the whole VSCode train so probably something I'm missing.

The grand parent is talking about code execution can happen by just opening the directory, you’re imagining like I did (and the grandparent) that you have to run or execute something in VSC to get that to happen and I’m asking about what features could possibly require this to happen. Obviously running tests or a make file everyone understands clearly you’re executing other people’s code.

It’s not even running tests. Test extensions usually have to run something to even populate the tests panel in my first place and provide the ability to run à la carte. Thus opening a folder will cause the test collector binary to run.
Post reply on HN