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

191–200 of 306 posts

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#191

Post by EGreg »

jasode wrote: post #172
mjdv wrote: post #121

Earlier quoted context omitted.

Until this post it wasn't clear to me that just opening and trusting a directory can cause code to be run without taking any other explicit actions that seem like they might involve running code, like running tests. My bad, but still!

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 software to AT LEAST warn peole when it’s about to take a destructive action, and keep asking until the user allows that class of thing non-interactivlely ONLY FOR THAT SIGNED SOFTWARE?

Apple does other software things really badly with their millions of dollars, but they get Privacy RIGHT: https://www.youtube.com/watch?v=XPogdNafgic

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#192

Post by Cthulhu_ »

Nathanba wrote: post #187
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...

It's worded really badly, so vscode is the thing that provides the dangerous features? No problem, I know and trust vscode. What the message should be warning about is that the folder may contain dangerous code or configuration values that can execute upon opening due to vscode features that are enabled by default. That sounds worse for them but that would be honest.

But you, as a security conscious software developer, know that the phrase "may automatically execute files" can also be "with malicious intent" - the tradeoff that whoever made the text (and since it's open source it's likely been a committee talking about it for ages) had to make is conciseness vs clarity. Give people too much text and they zone out, especially if their objective is "do this take home exercise to get a job" instead of "open this project carefully to see if there's any security issues in it".

This problem goes back to uh... Windows Vista. Its predecessors made all users an admin, Vista added a security layer so that any more dangerous tasks required you to confirm. But they went overboard and did it for anything like changing your desktop background image, and very quickly people got numb to the notice and just hit 'ok' on everything.

Anyway. In this particular case, VS Code can be more granular and only show a popup when the user tries to run a task saying something like "By permitting this script to run you agree that it can do anything, this can be dangerous, before continuing I'm going to open this file so you can review what it's about to do" or whatever.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#193

Post by elzbardico »

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.

Eclipse was always a confusing product. It was a bastard child of Visual Age for Java from IBM, which was already a bastard of IBM's Visual Age for Smalltalk.

Visual Age for Java had some quirkiness being a Smalltalk IDE adapted to Java development (for example, the concept of a file and a hierarchical filesystem itself was definitely a second class citizen in Visual Age) and eclipse kind of rounded those rough edges.

But Eclipse became a victim of late 90s/early 2000s academic driven overengineering with overly complex/bureaucratic stuff like OSGI, and the support for the absurdly bureaucratic java development ecosystem at that time.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#194

Post by tentacleuno »

realusername wrote: post #149
pmontra wrote: post #108

My first reaction has been: when we install some node modules, import them and eventually run them, we do grant local execution permissions to whatever the authors of those modules coded in their scripts, right? More or less every language already suffer from the same problem. Who vets the code inside a Ruby gem, a Python package, etc? Add your favorite language. However I did not know about tasks.json (I don't use V…

The reason it's worse in the js ecosystem is that you need way more packages than your average language to build anything functional.

You don't really need more packages. There's definitely a culture of creating ridiculously small packages, though.

If you spend enough time in the ecosystem, you'll begin to realise that a select few are very well known for doing this; one in particular made a package for every ANSI terminal colour.

left-pad (and quite a few incidents afterwards) were definitely wakeup calls, and I like to think we've listened in some ways.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#195

Post by javcasas »

echoangle wrote: post #113
pmontra wrote: post #108

My first reaction has been: when we install some node modules, import them and eventually run them, we do grant local execution permissions to whatever the authors of those modules coded in their scripts, right? More or less every language already suffer from the same problem. Who vets the code inside a Ruby gem, a Python package, etc? Add your favorite language. However I did not know about tasks.json (I don't use V…

You get asked if you trust the folder you’re opening every single time you open a new folder in VsCode. Everyone probably always just says yes but it’s not like it doesn’t tell you that opening untrusted folders is dangerous.

autorun.inf flashbacks.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#197

Post by Tyriar »

StingyJelly wrote: post #128
jhancock wrote: post #105

In VS Code settings search for "tasks" you will find "Task: Allow Automatic Tasks"...turn it off. Anything else that should be locked down?

This may only provide a flalse sense of security. Afaik, there is no way to disable workspace settings taking priority over user settings, so a malious repo can easily override them and reenable automatic tasks.

Various settings are `restricted` in the codebase to only use them when the workspace is trusted. `allowAutomaticTasks` is one such setting: https://github.com/microsoft/vscode/blob/f7730c409e14af94d75...

So a malicious repo can easily override it... if you say you trust it.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#198

Post by DrBazza »

boomlinde wrote: post #164
DrBazza wrote: post #130

Earlier quoted context omitted.

> Why is VS code the defacto answer nowadays? For what I do, there's no reasonable alternative at the moment. I'm sure someone will correct me, but it's the only editor that correctly (for some definition of correct) allows remote editing and devcontainers: [desktop OS] -> ssh -> [dest box] [desktop OS] -> [devcontainer] [desktop OS] -> ssh -> [dest box] -> [devcontainer] [desktop OS] -> ssh (jumphost) -> [dest box]…

I would rather solve file access at an entirely different level. A filesystem is a reasonable, editor-agnostic abstraction for this, and I can use sshfs to mount a remote directory over SSH in a way that's invisible to whatever tools I prefer to use to edit the files. If you have a jumphost chain, you can configure that in the SSH config. I don't know what a devcontainer is exactly, but if it's a container in the sen…

File access isn't the same as tool access. You need to run tools on your ssh host as well. And a devcontainer does indeed equal a (docker) container. The name is very specific and describes shipping a full developer environments so that 'you' do not have to install gcc-toolset-15, or boost 1.83, or mold, or python 3.11, and so on.

https://containers.dev/

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#199

Post by Tyriar »

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 vulnerable if you trust the workspace. VS Code is an IDE and the core and extensions can execute code based on files within the folder in order to provide rich features like autocomplete, compilation, run tests, agentic coding, etc.

Before workspace trust existed, we started noticing many extensions and core features having their own version of workspace trust warnings popping up. Workspace trust unified this into a single in your face experience. It's perfectly fine to not trust the folder, you'll just enter restricted mode that will protect you and certain things will be degraded like language servers may not run, you don't be able to debug (executes code in vscode/launch.json), etc.

Ultimately we're shipping developer tool that can do powerful things like automating project compilation or dependency install when you open a folder. This attack vector capitalizes on neglectful developers that ignore a scary looking security warning. It certainly happens in practice, but workspace trust is pretty critical to the trust model of VS Code and is also an important part to improve the UX around it as we annoy you a _single_ time when you open the folder, not several times from various components using a JIT notification approach. I recall many discussions happening around the exact wording of the warning, it's a difficult to communicate concept in the small amount of words that it needs to use.

My recommendation is to use the check box to trust the parent or configure trusted folders. I personally have all my safe git clones in a dev/ folder which I configured to trust, but I also have a playground/ folder where I put random projects that I don't know much about and decide at the time I open something.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#200

Post by theamazing0 »

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,

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