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

211–220 of 306 posts

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#211

Post by Tyriar »

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 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 curious what would stop you from opening it in restricted mode? Is it because it says browse and not edit under the button?

> Your recommendation makes sense as a strategy to follow ahead of time, before you're in that flow state.

You get the warning up front when you open a folder though, isn't this before you're in a flow state hacking away on the code?

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#212

Post by CWuestefeld »

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…

This demonstrates the actual real-world problem, though. You're saying "this is a complex problem so I'm going to punt and depend on the user to resolve it". But in real life, the user doesn't even know as much as you do about how Code and its plugins interact with their environment. Knowledgewise, most users are not in a good position to evaluate the dangers. And even those who could understand the implications are concentrating on their goal of the moment and won't be thinking deeply about it.

You're relying the wrong people, and at the wrong time, for this to be very effective.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#213

Post by Tyriar »

ycombinatrix wrote: post #210
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…

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.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#214

Post by weaksauce »

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!

yeah me as well. at least have the untrusted code allow certain plugins or certain features of plugins to run that you whitelist. not having vim keybindings or syntax highlighting is too barebones.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#215

Post by PunchyHamster »

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…

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 result at end of the session in form of a separate process that applies the AI changes as set of commits (NOT commiting direct file changes back as then malicious code could say mess stuff up in .git dir like adding hooks). That way at very worst you're some commit reverts out in main repo.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#216

Post by CWuestefeld »

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…

> Trusting this folder means code within it may be executed automatically.

But as you point out elsewhere, what constitutes code is very context dependent. And the user isn't necessarily going to be sufficiently expert on how Code interacts with the environment to evaluate that context.

> I'm curious what would stop you from opening it in restricted mode?

Even after years of using Code, I don't know the precise definition of "restricted mode". Maybe I ought to, but learning that isn't at the top of my list of priorities.

> You get the warning up front when you open a folder though, isn't this before you're in a flow state hacking away on the code?

NO! Not even close! And maybe this is at the heart of why we're not understanding each other.

My goal is not to run an editor and change some characters, not at all. It's so far down the stack that I'm scarcely aware of it at all, consciously. My goal is to, e.g., find and fix the bug that the Product Manager is threatening to kill me over. In order to do that I'm opening log files in weird locations (because they were set up by some junior teammate or something), and then opening some code I've never seen before because it's legacy stuff 5 years old that nobody has looked at since; I don't even have a full picture of all languages and technologies that might be in use in this folder. But I do know for sure that I need to be able to make what edits may turn out to be necessary half an hour from now once I've skimmed over the contents of this file and its siblings, so I can't predict for sure whether whatever the heck "restricted mode" will do to me will interfere with those edits.

I'm pretty sure that the above paragraph represents exactly what's going on in the user's mind for a typical usage of Code.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#218

Post by CjHuber »

theamazing0 wrote: post #200
CjHuber wrote: post #163

Earlier quoted context omitted.

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,

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.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#219

Post by andy_ppp »

__jonas wrote: post #186
andy_ppp wrote: post #129

Earlier quoted context omitted.

What is the stated reasoning for arbitrary code execution as a feature? Seems pretty mad to me.

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.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#220

Post by Tyriar »

_bent wrote: post #203
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 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 code, opening it should make that work well. The expectation is that most users should trust almost all their windows, it's an edge case for most developers to open and browse unfamiliar codebases that could contain such attacks. It also affects not just code editing but things like workspace settings so the editor could work radically different when you trust it.

You make a good point about the cookie banner reflex, but you don't need to use accept all on those either.

Post reply on HN