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

161–170 of 306 posts

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#161

Post by direwolf20 »

andy_ppp wrote: post #158
direwolf20 wrote: post #131

Earlier quoted context omitted.

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.

Some project types, such as Gradle or Maven projects, use arbitrary commands or plugins in project setup. You have to run arbitrary plugins to know which directories are the source directories, and you have to know which directories are the source directories to do anything in Java.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#163

Post by CjHuber »

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

I don't like the way it is handled. Imagine Excel actively prompting you with a pop up every time you open a sheet: "Do you trust the authors of this file? If not you will loose out on cool features and the sheet runs in restricted mode"

No it doesn't because restricted mode without Macros is the default and not framed like something bad or loosing out on all of those nice features,

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#164

Post by boomlinde »

DrBazza wrote: post #130
TheAdamist wrote: post #2

Coming from the perspective of an eclipse fan, why is VS code the defacto answer nowadays? Im forced to use vs code (so biased), but everything seems worse than eclipse, plus these repeated security issues from malware laced projects. Theres been several posts about infected projects by fake recruiters here in the last year or two. Im guessing the answer is probably Java is why eclipse is out of favor.

> Why is VS code the defacto answer nowadays? For what I do, there's no reasonable alternative at the moment. I'm sure someone will correct me, but it's the only editor that correctly (for some definition of correct) allows remote editing and devcontainers: [desktop OS] -> ssh -> [dest box] [desktop OS] -> [devcontainer] [desktop OS] -> ssh -> [dest box] -> [devcontainer] [desktop OS] -> ssh (jumphost) -> [dest box]…

I would rather solve file access at an entirely different level. A filesystem is a reasonable, editor-agnostic abstraction for this, and I can use sshfs to mount a remote directory over SSH in a way that's invisible to whatever tools I prefer to use to edit the files.

If you have a jumphost chain, you can configure that in the SSH config.

I don't know what a devcontainer is exactly, but if it's a container in the sense that it runs a Linux development system, I would investigate whether that, too, could easily be set up for access via SSH or mounted locally through some other mechanism.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#165

Post by azornathogron »

IshKebab wrote: post #107
EE84M3i wrote: post #8

Earlier quoted context omitted.

Doesn't it ask you if you trust a folder when you open it?

Yeah but it's one of those useless permission requests along the lines of "Do you want this program to work or not?" They're pawning off responsibility without giving people a real choice. It's like the old permission dialog for Android that was pretty much "do you want to use this app?". Obviously most people just say yes. There's a reason Google changed that. To be fair I'm sure Microsoft would switch to a saner pe…

It's not a false choice - "Trust" and "don't trust" are both perfectly viable options. The editor works fine in restricted mode, you just won't have all your extensions enabled.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#166

Post by jotaen »

rcxdude wrote: post #154
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.

> in general people would like their IDE to run language servers, set up build systems, and any number of other things

That I understand, I’m mainly wondering why all that would have to happen automatically by merely opening a folder.

My personal preference may differ here, but for things like running a build or starting a dev server, I usually prefer to trigger them manually, and not have them silently executed only by me browsing through the sources.

Therefore I’m trying to understand whether there are legitimate use-cases for this “auto-run on open folder” feature besides the obvious convenience aspect of saving one or two extra clicks.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#167

Post by andy_ppp »

direwolf20 wrote: post #161
andy_ppp wrote: post #158

Earlier quoted context omitted.

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.

Some project types, such as Gradle or Maven projects, use arbitrary commands or plugins in project setup. You have to run arbitrary plugins to know which directories are the source directories, and you have to know which directories are the source directories to do anything in Java.

There’s no need to run that when opening a directory is there?

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#168

Post by ses1984 »

CjHuber wrote: post #163
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...

I don't like the way it is handled. Imagine Excel actively prompting you with a pop up every time you open a sheet: "Do you trust the authors of this file? If not you will loose out on cool features and the sheet runs in restricted mode" No it doesn't because restricted mode without Macros is the default and not framed like something bad or loosing out on all of those nice features,

The point of an IDE is that it does stuff a simple text editor does not.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#169

Post by Levitz »

nottorp wrote: post #140
EE84M3i wrote: post #8

Earlier quoted context omitted.

Doesn't it ask you if you trust a folder when you open it?

I always wondered why. Now I finally know that it auto runs code in that folder. Who thought this is a good idea and why wasn't it specified in ALL CAPS in that dialog? Is it even documented anywhere? Very infrequent vscode user here, beginning to think it's some kind of Eclipse.

I mean it's not in caps, but it's literally the first line in the dialog after the header:

https://code.visualstudio.com/docs/editing/workspaces/worksp...

I'm big on user first, if that dialog had sirens blaring, a gif and ten arrows pointing that "THIS MAY EXECUTE CODE" and people still didn't get the idea, I'd say it needs fixing. It can't be said that they didn't try or that they hid it though.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#170

Post by andy_ppp »

arzig wrote: post #160
andy_ppp wrote: post #157

Earlier quoted context omitted.

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.

They could ask and/or parse the tests for the information rather than run them to output it. I’m honestly still not seeing a killer feature here that makes the security implications worth it!
Post reply on HN