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

281–290 of 306 posts

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#281

Post by spr93 »

Tyriar wrote: post #199

VS Code team member here :wave: As called out elsewhere, workspace trust is literally the protection here which is being circumvented. You're warned when you open a folder whether you trust the origin/authors with pretty strong wording. Sure you may find this annoying, but it's literally a security warning in a giant modal that forces you to chose. Even if automatic tasks were disabled by default, you'd still be vuln…

Meet the new Microsoft - same as the old one. This is the same reasoning that led to a decade of mindnumbingly obvious exploits against Internet Explorer. You've got to create secure defaults. You have to ask whether your users really want or need some convenience that comes at the expense of an increased attack surface.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#282

Post by skybrian »

artbristol wrote: post #270
skybrian wrote: post #265

I'm moving all my development to a remote VM so I can use a coding assistant without worrying too much. I use VS Code's "Remote - SSH" plugin to connect. I'm wondering if that helps. If I "trust" a remote directory, is there an exploit that can get to my laptop? There's enough complicated machinery that I'm thinking the answer is likely yes, but perhaps this has been vetted.

Unfortunately according to Microsoft themselves, the answer is yes https://marketplace.visualstudio.com/items?itemName=ms-vscod... > A compromised remote could use the VS Code Remote connection to execute code on your local machine.

Ah well. Since I'm mostly reading code in the VM, I should come up with a better file browser.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#283

Post by DrewADesign »

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.

Until you actually do any of those things, an IDE is a fancy text editor.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#284

Post by giantg2 »

eikenberry wrote: post #6
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.

Seems very odd to me that someplace would force the use of a particular development tool. I've seen it only one time while interviewing, where they wanted everyone to have identical setups so they could easily hop onto each others computers when needed... it was weird and I took it as a red flag and didn't follow through them them.

Licensing issues and security configuration management are major reasons to want uniformity.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#285

Post by CjHuber »

6mile wrote: post #277
Tyriar wrote: post #199

VS Code team member here :wave: As called out elsewhere, workspace trust is literally the protection here which is being circumvented. You're warned when you open a folder whether you trust the origin/authors with pretty strong wording. Sure you may find this annoying, but it's literally a security warning in a giant modal that forces you to chose. Even if automatic tasks were disabled by default, you'd still be vuln…

Hi, I'm one of the researchers that identified this threat and I blogged about it back in November ( https://opensourcemalware.com/blog/contagious-interview-vsco... ) First, @Tyriar thanks for being a part of this conversation. I know you don't have to, and I want to let you know I get that you are choosing to contribute, and I personally appreciate it. The reality is that VS Code ships in a way that is perfect for a…

Oh wow that's the first time I've heard about those tasks. I would never consent to that and that they are enabled by default and shipped in the .vscode folder where most people probably nevereven would have thought about looking for malicious things that's kind of insane.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#286

Post by HALtheWise »

slightwinder wrote: post #244
Tyriar wrote: post #206

Earlier quoted context omitted.

It's not just the .vscode folder though, the Python extension for example executes code in order to provide language services. How could this threat detection possibly be complete? In this new LLM-assisted world a malicious repository could be as innocuous as a plain text prompt injection attack hidden in a markdown file, or some random command/script that seems like it could be legitimate. There are other mitigation…

> It's not just the .vscode folder though, the Python extension for example executes code in order to provide language services. Which code? Its own Code (which the user already trusts anyway), or code from the workspace (automatically)? My expectation with a language-server is that it never code from the workspace in a way which could result in a side effect outside the server gaining understanding about the code. S…

Your expectation is wrong in this case for almost all languages. The design of Pylance (as is sorta forced by Python itself) chooses to execute Python to discover things like the Python version, and the Python startup process can run arbitrary code through mechanisms like sitecustomize.py or having a Python interpreter checked into the repo itself. To my knowledge, Go is one of the few ecosystems that treats it as a security failure to execute user-supplied code during analysis tasks, many languages have macros or dynamic features that basically require executing some amount of the code being analyzed.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#287

Post by dragonwriter »

nacs wrote: post #224
Tyriar wrote: post #211

Earlier quoted context omitted.

> I don't have a flash of insight over what my risk exposure might be for what I'm opening at this moment Maybe I'm too close to it, but the first sentence gives a very clear outline of the risk to me; Trusting this folder means code within it may be executed automatically. > I don't have a comprehensive picture of all the implications, all I'm thinking is "I need to open this file and twiddle some text in it". I'm c…

Thanks for being part of the discussion. Almost every response from you in this thread however comes off an unyielding, "we decided this and it's 100% right"? In light of this vulnerability, the team may want to revisit some of these assumptions made. I guarantee the majority of people see a giant modal covering what they're trying to do and just do whatever gets rid of it - ie: the titlebar that says 'Trust this wor…

> Almost noone is going to read some general warning about how it "may" execute code. At the very least, scan the project folder and mention what will be executed (if it contains anything).

I’m not sure this is possible or non-misleading at the time of granting trust because adding or updating extensions, or changing any content in the folder after trust is granted, can change what will be executed.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#288

Post by EGreg »

WorldMaker wrote: post #251
EGreg wrote: post #191

Earlier quoted context omitted.

Oh man! Microsoft was the #1 company with this problem for over 25 years and they still do it? Word and Excel “MACROS” used to be THE main vector for kiddie viruses. Come on M$ … billions of dollars and you’re still loading up non-interactive code execution in all your documents that people expect to be POD (Plain Old Data)? https://support.microsoft.com/en-us/office/protect-yourself-... Is it so much to ask for your…

VS Code does exactly that, warns before loading this non-interactive code. It warns you loudly, with an ugly modal dialog, on opening a new to it folder and suggests Restricted Mode. A lot of the arguments here relate to: 1) This loud warning is easy to ignore, despite how loud it is 2) This loud warning is easy to disable, which many desire to do because it is very loud 3) This loud warning is easy to build bad habi…

No, not loading code. Executing dangerous actions. There is a huge difference. Watch the video I had linked to!

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#289

Post by WorldMaker »

EGreg wrote: post #288
WorldMaker wrote: post #251

Earlier quoted context omitted.

VS Code does exactly that, warns before loading this non-interactive code. It warns you loudly, with an ugly modal dialog, on opening a new to it folder and suggests Restricted Mode. A lot of the arguments here relate to: 1) This loud warning is easy to ignore, despite how loud it is 2) This loud warning is easy to disable, which many desire to do because it is very loud 3) This loud warning is easy to build bad habi…

No, not loading code. Executing dangerous actions. There is a huge difference. Watch the video I had linked to!

Maybe I'm confused at what you mean, but I don't think there's a huge difference. Loading code is a dangerous action. VS Code is doing exactly what the video is talking about: it gives you a big popup window before doing a dangerous action (that could violate your privacy, that could be malware, that could do things you don't expect).

We want to load code in Turing complete languages. We want complex build tools and test harnesses to load "just so", and those too are generally Turing complete and configured and written in Turing complete languages. Parsing code in a Turing complete language takes another Turing complete language, generally. (Most languages are self-hosted so parsing the code is an action in that same language.)

One of the most dangerous actions we know of is an ancient and inescapable "bug" in all Turing complete work: the Halting Problem. We cannot mathematically prove any program will complete nor when it will complete, without running it and waiting for it to complete, if it completes. Infinite loops are both the power granted to us by our tools and the potential downfall of them all, our responsibility to deal with them is in our hands and math can't help us enough.

Loading code is a dangerous action. VS Code is doing the right thing in how it is handling it. It's not the best user experience and clearly not enough users understand the dangers inherent in "do you really want to run all your extensions in this folder?" in precisely the same way that people better understand "Do you want this application to have access to your precise location?" is a threat (that apps do take advantage; in both cases).

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#290

Post by oenton »

Tyriar wrote: post #211
CWuestefeld wrote: post #204

Earlier quoted context omitted.

I suspect that you're relying too heavily on the user here. Even for myself, a very experienced developer, I don't have a flash of insight over what my risk exposure might be for what I'm opening at this moment. I don't have a comprehensive picture of all the implications, all I'm thinking is "I need to open this file and twiddle some text in it". Expecting us to surface from our flow, think about the risks and make…

> I don't have a flash of insight over what my risk exposure might be for what I'm opening at this moment Maybe I'm too close to it, but the first sentence gives a very clear outline of the risk to me; Trusting this folder means code within it may be executed automatically. > I don't have a comprehensive picture of all the implications, all I'm thinking is "I need to open this file and twiddle some text in it". I'm c…

For what it's worth, I absolutely agree with the comments saying the warning doesn't clearly communicate the risks. I too had no idea opening a directory in VS Code (that contains a tasks.json file) could cause some code to execute. I understood the risk of extensions but I think that's different, right? i.e. opening a trusted project doesn't automatically install extensions when there's an extensions.json (don't quote me on that, unless that's correct)

To give some perspective: VS Code isn't my primary IDE, it's more like my browsing IDE. I use it to skim a repo or make minor edits, without waiting for IntelliJ to index the world and initialize an obscene number of plugins I apparently have installed by default. Think—fixing a broken build. If I'm only tweaking or reinstalling dependencies because the package-lock file got corrupted and that's totally not something that happened this week, I don't need all the bells and whistles. Actually I want less because restarting the TypeScript service multiple times is painful, even on a high end Mac.

Anyway enough about IntelliJ. This post has some good discussions and I sincerely hope that you (well, and Microsoft) take this feedback seriously and do something about it. I imagine that's hard, as opposed to say , but this is what matters. Remember what Steve Ballmer said about UAC? I don't know if he said anything, but if it didn't work then it's not going to work now.

Post reply on HN