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

261–270 of 306 posts

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#261

Post by rsyring »

sbarre wrote: post #245
weaksauce wrote: post #239

Earlier quoted context omitted.

> I'm curious what would stop you from opening it in restricted mode? Is it because it says browse and not edit under the button? loss of syntax highlighting and to a lesser extent the neovim plugin. maybe having some kind of more granular permission system or a whitelist is the answer here. opening a folder in vscode shouldn't be dangerous.

> opening a folder in vscode shouldn't be dangerous. You're not "opening a folder" though, you're opening a codebase in an IDE, with all the integrations and automations that implies, including running code. As a developer it's important to understand the context in which you're operating. If you just want to "open a folder" and browse the contents, that's literally what Restricted mode is for. What you're asking to…

I've been using VS Code for many years and I try pretty hard to be a security aware dev.

I checkout all code projects into ~/projects. I don't recall ever seeing a trust/restricted dialogue box. But, I'm guessing, at some point in the distant past, I whitelisted that folder and everything under it.

I've only just now, reading through this thread, realized how problematic that is. :o/

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#262

Post by wvenable »

perryizgr8 wrote: post #96
AmazingTurtle wrote: post #92

"Code provides features that may automatically execute files in this folder. If you don't trust the authors of these files, we recommend to continue in restricted mode as the files may be malicious." If you proceed with "Trust Project" you're at your own fault.

The "trust project" feature has been designed to be so extremely intrusive and annoying that the first thing I do is to completely disable it whenever I install VS Code on a new computer. This "solution" was just done to tick some box and put the blame on the user when a security incident happens. It's pretty similar to Windows Vista where it annoyed you with a disruptive popup so many times during the normal course…

> It's pretty similar to Windows Vista where it annoyed you with a disruptive popup so many times during the normal course of actions that most people ended up disabling the whole UAC system.

Nothing changed post-Vista. It's exactly the same system in Windows 11 doing exactly the same thing. It did, however, get developers to change how they do things.

To be honest, the solution here is probably more dialogs like this, not less. Having one single "Trust everything here but if you don't then nothing will work" box is hardly a good way to go.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#264

Post by edf13 »

CWuestefeld wrote: post #204
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…

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’d like more granular controls - sometimes I don’t want to trust the entire project but I do want to trust my elements of it

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#265

Post by skybrian »

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.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#266

Post by gambiting »

godelski wrote: post #260
gambiting wrote: post #248

Earlier quoted context omitted.

>>Don't you have partial compiles? Parallel compiling? We do. Without it it it takes over 3 hours for a full project build. Normally if I change one line of code and hit "run" it takes ~10-15 minutes for the app to start, depending on which file I changed. >>Upgrade your machine? It's a 64 core/128 thread core Threadripper workstation with 256GB of ram, so not many upgrade options from that. It's a huge C++ project,…

Okay so in your unique situation I'll agree that the load times and resource consumption isn't meaningful if you agree your situation is not the norm

Lol this isn't unique nor out of the norm - most big C++ projects are like this, and certainly every one in my industry(video games), unless you're trying to make an argument that C++ is somehow not commonly used. I even worked on a small indie game in C++ and it took 5 minutes minimum to compile.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#267

Post by ethersteeds »

rvz wrote: post #38

A great reason why you should switch to Zed.

I was reminded of this comment when I saw the latest Zed release removing a list of tool calls from the default always_allow list. Yikes!

https://github.com/zed-industries/zed/compare/v0.220.2...v0....

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#268

Post by cookiengineer »

CWuestefeld wrote: post #204
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…

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…

The funny part is that everyone expects you to make an informed decision about your security, without even providing any data to make that decision.

A better strategy would be:

- (seccomp) sandbox by default

- dry run, observe accessed files and remember them

- display dialog, saying: hey this plugin accesses your profile folder with the passwords.kdbx in it? You wanna allow it?

In an optimum world this would be provided by the operating system, which should have a better trust model for executing programs that are essentially from untrustable sources. The days where you exactly know what kind of programs are stored in your folders are long gone, but for whatever reason no operating system has adapted to that.

And before anyone says the tech isn't there yet: It is, actually, it's called eBPF and XDP.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#269

Post by CWuestefeld »

socalgal2 wrote: post #258
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…

How is this any different than anything else devs do? Devs use `curl some-url | sh`. Devs download python packages, rust crates, ruby gems, npm packages, all of them run code. At some point the dev has to take responsibility.

Devs download python packages, rust crates, ruby gems, npm packages, all of them run code.

You allow developers to download and run arbitrary packages? Where I came from, that went out years ago. We keep "shrinkwrap" servers providing blessed versions of libraries. To test new versions, and to evaluate new packages, there's a highly-locked-down lab environment.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#270

Post by artbristol »

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.

Post reply on HN