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

241–250 of 306 posts

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#241

Post by Aurornis »

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…

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

Have you tried it? It breaks a lot of things that I would not have expected from the dialog. It’s basically regressing to a slightly more advanced notepad.exe with better grepping facilities in some combinations of syntax and plugins.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#242

Post by godelski »

rmunn wrote: post #37
godelski wrote: post #28

Earlier quoted context omitted.

Load time is in seconds, even with the program cached. I can still load vim with a ton of plugins[0] and still load a project in a few hundred milliseconds. Maybe VS Code is faster with fewer plugins but it's still "dog slow" to load and run. Only thing I'm "missing" in vim is the bloat [0] personal I only use a handful but I've played around because why not

With LazyVim (requires NeoVim) and its load-on-demand architecture, startup time usually stays below 50 milliseconds even with a ton of plugins. Below 50ms is fast enough that it feels instant . Aliasing `nvim` to `n` in my ~/.bash_aliases just makes it even faster. cd to a project directory, run `n .` and I'm looking at the NeoVim file explorer plugin for that project directory. No break in thought flow, no standing…

To be honest I was giving myself some leeway. I'm pretty sure I'm loading in well below 100ms. It feels instant

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#243

Post by sbarre »

Aurornis wrote: post #241
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…

> 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? Have you tried it? It breaks a lot of things that I would not have expected from the dialog. It’s basically regressing to a slightly more advanced notepad.exe with better grepping facilities in some combinations of syntax and plugins.

Isn't that what you would want if you're opening an untrusted codebase?

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#244

Post by slightwinder »

Tyriar wrote: post #206
pezgrande wrote: post #202

Earlier quoted context omitted.

would it possible to show to alert only when there are potentials threats instead of every time a folder is open? Like showing a big red alert when opening a folder for the first time with a ".vscode" folder in it?

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. So this makes little sense?

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#245

Post by sbarre »

weaksauce wrote: post #239
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…

> 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 do is already there.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#246

Post by dwallin »

Tyriar wrote: post #220
_bent wrote: post #203

Earlier quoted context omitted.

I think it would be better to defer the Workspace trust popup and immediately open in restricted mode; maybe add an icon for it in the bottom info bar & have certain actions notify the user that they'd have to opt in before they'd work. Because right now you are triggering the cookie banner reflex where a user just instinctively dismisses any warnings, because they want to get on with their work / prevent having thei…

Some JIT notification to enable it and/or a status bar/banner was considered, but ultimately this was chosen to improve the user experience. Instead of opening a folder, having it restricted and editing code being broken until you click some item in the status bar, it's asked up front. It was a long time ago this was added (maybe 5 years?), but I think the reasoning there was that since our code competency is editing…

IMO this is a mistake, for basically the same reason you justify it with. Since most people just want the code to work, and the chances of any specific repo being malicious is low, especially when a lot of the repos you work with are trusted or semi-trusted, it easily becomes a learned behavior to just auto accept this.

Trust in code operates on a spectrum, not a binary. Different code bases have vastly different threat profiles, and this approach does close to nothing to accomodate for that.

In addition, code bases change over time, and full auditing is near impossible. Even if you manually audit the code, most code is constantly changing. You can pull an update from git, and the audited repo you trusted can be no longer trustworthy.

An up front binary and persistent, trust or don't trust model isn't a particularly good match match for either user behavior or the potential threats most users will face.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#247

Post by godelski »

gambiting wrote: post #119
godelski wrote: post #28

Earlier quoted context omitted.

Load time is in seconds, even with the program cached. I can still load vim with a ton of plugins[0] and still load a project in a few hundred milliseconds. Maybe VS Code is faster with fewer plugins but it's still "dog slow" to load and run. Only thing I'm "missing" in vim is the bloat [0] personal I only use a handful but I've played around because why not

>>Load time is in seconds, even with the program cached. Are you like, for real? How often do you load it up for it to matter in the slightest? Do you not just open the project once at the start of the day and then continue working? Sorry but for someone used to working in VS proper and projects which take minimum 40 minutes to build, saying that a startup time of a few seconds is a problem is.....just hard to unders…

  > 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 compiling? Upgrade your machine?

But it's not just startup time. I use less RAM, less CPU resources, jumping through tags is instant, working through the debugger is instant, opening new files is instant, fuzzy searching my system is instant. It sounds like the program you're working on and your editor are fighting for resources and I've never faced that problem with vim

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#248

Post by gambiting »

godelski wrote: post #247
gambiting wrote: post #119

Earlier quoted context omitted.

>>Load time is in seconds, even with the program cached. Are you like, for real? How often do you load it up for it to matter in the slightest? Do you not just open the project once at the start of the day and then continue working? Sorry but for someone used to working in VS proper and projects which take minimum 40 minutes to build, saying that a startup time of a few seconds is a problem is.....just hard to unders…

> 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, heavily templated, that's kinda normal. My previous 2 projects were also like this.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#249

Post by godelski »

vanviegen wrote: post #91
rmunn wrote: post #37

Earlier quoted context omitted.

With LazyVim (requires NeoVim) and its load-on-demand architecture, startup time usually stays below 50 milliseconds even with a ton of plugins. Below 50ms is fast enough that it feels instant . Aliasing `nvim` to `n` in my ~/.bash_aliases just makes it even faster. cd to a project directory, run `n .` and I'm looking at the NeoVim file explorer plugin for that project directory. No break in thought flow, no standing…

Your focus on startup speed feels really alien to me. When working on a project I just keep vscode open. I reboot maybe once a week and starting vscode again takes about a second, and then maybe 10s of seconds of background processing, depending on the project size, for the language server to become fully operational. That's more than good enough for me. I've done a lot of shell-driven development in the 00s though,…

  > starting vscode again takes about a second, and then maybe 10s of seconds of background processing
Yet I'm doing the same thing instantly or near instantly.

I don't reboot often and I'm still lazy and will leave projects open often, but honestly, have you considered that your workflow is an adaptation to the wait time?

  > Navigating between files (using fuzzy search or go-to-definition) is just a lot faster and more convenient.
I agree? But why do you think people don't fuzzy search in vim? Or the terminal? There's been tools to do this for a very long time. Fzf is over a decade old and wasn't the first

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#250

Post by com2kid »

jhasse wrote: post #110
com2kid wrote: post #33

Earlier quoted context omitted.

People forget that there was a period of time during which the Java runtime installer tried to install actual adware. You had to jump through hoops to deselect adware from being forced onto your machine, it was infuriating. Setting up a new machine, I could choose between Eclipse (free, took forever to open, slow, asked me a million questions before it let me start working) or Visual Studio (cost money, incredibly po…

Visual Studio is mostly written in C# btw.

Back in 2005 it was mostly in C++ and it was blazing fast. IMHO VS 2005 was the most performant edition. I never liked VS 2003, felt bloated in comparison.
Post reply on HN