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

251–260 of 306 posts

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#251

Post by WorldMaker »

EGreg wrote: post #191
jasode wrote: post #172

Earlier quoted context omitted.

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…

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 habits (instead of marking safe parent folders, continually clicking Allow and training yourself to only click Allow)

4) Restricted Mode sounds "too restricted" to be useful (though it isn't too restrictive and is very useful)

5) Restricted Mode is also loud to remind you that you are in it, so many users think it is too loud and never want to be in it (despite it being very useful)

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#252

Post by WorldMaker »

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,

Right, I think one of the biggest problems is the name "Restricted Mode" itself. It sounds like a punishment, when it is a safer sandbox. Restricted Mode is great and incredibly useful. But it is unsurprising how people don't like to be in Restricted Mode when it sounds like a doghouse out back, not a lobby or atrium on the way to the rest of the building.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#253

Post by WorldMaker »

CjHuber wrote: post #218
theamazing0 wrote: post #200

Earlier quoted context omitted.

I think Excel does do something similar though with Protected View. https://support.microsoft.com/en-us/office/what-is-protected...

Exactly that's why I was making the comparison, It's not a in your face PopUp, where users get used to just pressing the blue, highlighted and glowing "I trust the authors" button without even being told what features they'd miss out on. The Protected view in Office instead tells you "Be careful" and to only activate editing when you need to.

It's also worth noting that this behavior evolved very slowly. It took Excel decades to learn how to best handle the defaults. Excel started with modals similar to VS Code's "Do you want to allow macros? This may be dangerous", found too many users self-trained on "Allow" as the only button that needed to be pressed and eventually built the current solution.

If VS Code is still on the same learning curve, hopefully it speeds up a bit.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#254

Post by unium »

jFriedensreich wrote: post #225

I am fully moving from local electron based vscode to using vscode-server inside docker inside a vm. It has just so many advantages besides security eg. being able to have multiple workspaces in tabs instead of separate electron windows, and having all the docker/vm tooling available. This can replace remote vscode, devcontainers and electron in a nice package. There is just no reality in which vscode with electron r…

Interesting. Link to custom browser repo?

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#255

Post by WorldMaker »

andy_ppp wrote: post #219
__jonas wrote: post #186

Earlier quoted context omitted.

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 wit…

Thanks! I think it would be better if these types of events were fine grained and you could decide if you wanted to run them the first time but I can understand them being enabled now.

More granular is more likely to train users on "Always Click Allow". The current modal dialog already has that problem and is just one O(N) dialog where N is the number of folders you open (modulo opt-outs). If you got O(N * M) of these where N is the number of folders and M is the number of tasks in tasks.json plus the number of Extensions installed that want to activate in the folder, a) you would probably go a little batty), and b) you would probably stop reading them quickly and just always click Allow.

(It can also be pointed out that a lot of these are granular under the hood. In addition to Restricted Mode as a generally available sandbox, you have all sorts of workspace level controls over tasks.json and the Extensions you have installed and active for that workspace. Not to mention a robust multi-profile system where you can narrow Extensions to specific roles and moods. But most of us tend to want to fall into habits of having a "kitchen sink" profile with everything always available and don't want to think about granular security controls.)

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#256

Post by twoWhlsGud »

Tyriar wrote: post #222
PunchyHamster wrote: post #215

Earlier quoted context omitted.

Dunno how to break it to you but most of the people using AI the most, they are not very good at computers. I think with AI we quickly progress to level where it needs to essentially run in nice lil isolated sandbox with underlying project (and definitely everything else around it) being entirely read only (in form on overlay FS or some similar solution), let it work in the sandbox and then have user only accept the…

AI certainly made everything in this area more complicated. I 100% agree about sandboxing and we have people investing in this right now, there's an early opt-in version we just landed recently in Insiders.

Interesting! Is there a pointer to an issue where this feature is described by chance?

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#257

Post by WorldMaker »

andy_ppp wrote: post #170
arzig wrote: post #160

Earlier quoted context omitted.

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!

The trouble is that "just parse the tests" isn't always an option and running arbitrary code is the nature of how software is built.

The easiest example is JS testing. Most test harnesses use a JS file for configuration. If you don't know how the harness is configured how do you know you are parsing the right tests?

Most test frameworks in JS use the define/it `define("some test colection", () => it("some test", () => /* …test code… */))` pattern. Tests are built as callbacks to functions.

In theory, sure, you could "just" try to RegEx out the `define("name"` and `it("name"` patterns, but it becomes harder to track nesting than you think it is with just RegEx. Then you realize that because those are code callbacks, no one is stopped from building meta-test suites with things like `for (thing of someTextMatrix) { it(`handles ${thing}`, () => /* …parametric test on thing… */ }`.

The test language used most in JS is JS. It's a lot harder problem than "just parsing" to figure out. In most cases a test harness needs to run the JS files to collect the full information about the test suite. Being JS files they are Turing Complete and open to doing whatever they want. Many times the test harnesses are running in a full Node environment with access to the entire filesystem and more.

Most of that applies to other test harnesses in other languages as well. To get the full suite of possible tests you need to be able to build that language and run it. How much of a sandbox that language has in that case shifts, but often it is still a sandbox with ways to escape. (We've proven that there's an escape Zero Day in the Universal Turing Machine, escapes are in some ways inevitable in any and all Turing Complete languages.)

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#258

Post by socalgal2 »

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…

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.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#259

Post by ycombinatrix »

Tyriar wrote: post #213
ycombinatrix wrote: post #210

Earlier quoted context omitted.

The grey bar at the top that says "this is an untrusted workspace" is really annoying & encourages users to trust all workspaces.

It's intentionally prominent as you're in a potentially very degraded experience. You can just click the x to hide it which is remembered the next time you open the folder. Not having this banner be really obvious would lead to frustrated users who accidentally/unknowingly ended up in this state and silly bug reports wasting everyone's time about language services and the like not working.

imo there's nothing "degraded" about editing text without arbitrary code execution. that's what text editors are supposed to do.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#260

Post by godelski »

gambiting wrote: post #248
godelski wrote: post #247

Earlier quoted context omitted.

> How often do you load it A few dozen times a day? I live in the terminal and opening files with vim is the primary way I interact with them. > Do you not just open the project once at the start of the day and then continue working? I mean I do this too > projects which take minimum 40 minutes to build This sounds problematic and a whole different category of problems. Don't you have partial compiles? Parallel compi…

>>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
Post reply on HN