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

271–280 of 306 posts

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#271

Post by SAI_Peregrinus »

rcxdude wrote: post #155
duskdozer wrote: post #144

Earlier quoted context omitted.

>Code provides features that may automatically execute files... What features? What files? "may"? So will it actually happen or is it just "well it possibly could"? I've used it to open folders that I personally made and which don't have any tasks or files that get automatically executed, and yet the message pops up anyway. It's like having an antivirus program that unconditionally flags every file as "this file may…

Yeah, because there are a lot of mechanisms by which a folder may start to execute code when you open it outside of restricted mode. A large fraction of addons have something which could be used for this, for example. There isn't a general check that it can apply ahead of time for this. (They could, with some breaking changes, maybe try to enforce a permissions system for the matrix of addons and folders, where it wo…

They could also, with a breaking change, enforce addons register what sorts of files they'll execute when a folder is opened in trusted mode. If no matching files are found, then opening the folder is safe and no prompt is needed. If matching files are found, then prompt the user and replace "may" with "will". Fewer permission requests, and a clearer message.

People will still inevitably ignore the message and open everything in trusted mode, but it'd be more reasonable to consider that user error.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#272

Post by MaulingMonkey »

sciencejerk wrote: post #39

Is tasks.json automatically run? I thought additional user interaction was required?

You can specify:

    "runOptions": { "runOn": "folderOpen" }
In tasks.json, which I use for automatically `git fetch`ing on a few projects. While I don't recall it's interaction with first run / untrusted folder dialogs, it's entirely automatic on second run / trusted folders.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#273

Post by godelski »

gambiting wrote: post #266
godelski wrote: post #260

Earlier quoted context omitted.

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.

C++ is common, but game programming definitely isn't the norm.

And 5 min is very different from 40 mins. Don't pretend a factor of 8 isn't insignificant

I've also worked on systems which are entirely written with template metaprogramming. This is definitely not the norm. Though that code was highly focused on optimization, as we were writing for HPC environments (extremely heterogeneous hardware). Sure, a full compile could take quite some time but doing a full compile, or even compiling a decent portion, when developing would be insane. A partial compile of a few minutes usually meant my time was better spent mucking about with the cmake and build files because incremental testing sped up development and your PRs aren't going to be merged quickly if they take an hour to verify if they even compile.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#274

Post by gambiting »

godelski wrote: post #273
gambiting wrote: post #266

Earlier quoted context omitted.

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.

C++ is common, but game programming definitely isn't the norm. And 5 min is very different from 40 mins. Don't pretend a factor of 8 isn't insignificant I've also worked on systems which are entirely written with template metaprogramming. This is definitely not the norm. Though that code was highly focused on optimization, as we were writing for HPC environments (extremely heterogeneous hardware). Sure, a full compil…

>>C++ is common, but game programming definitely isn't the norm.

I mean, last time I checked there are hundreds of thousands of programmers working in this industry, and video games are a bigger industry than movies. What's not the norm about it, exactly? I imagine there's more programmers out there making video games than making accounting software, for example.

>>And 5 min is very different from 40 mins. Don't pretend a factor of 8 isn't insignificant

I'm sorry, I'm confused. Did I ever imply otherwise? Maybe let me say it again, clearer - so far I worked at 2 big AAA studios, on 5 big AAA franchises, in 4 different engines. All 5 of those had those multi-hour compilation times unless you used something like Incredibuild or Fastbuild, and every single one of them had a startup of around 10+ minutes if you made any change to the code at all, just for VS to finish compilation and linking. I also worked at a small indie studio, with its own C++ engine, we had maybe...200 files max? That project took 5 minutes to build. Don't know where you got the idea that I'm saying factor of 8 is insignificant.

>> your PRs aren't going to be merged quickly if they take an hour to verify if they even compile.

Hmm at the current project the time from me submitting a change to it actually being accepted is ~6 hours. On my previous projects I think the fastest I've seen has been around an hour for a very very quick preflight. But then all the tests also have to pass which takes a lot of time.

>>ure, a full compile could take quite some time but doing a full compile, or even compiling a decent portion, when developing would be insane.

Right, but you have to do this at least once when you get latest, normally in the morning I grab latest and have to build around ~9000 files. If I make a change in the gameplay code it might have to recompile ~200-300 files because of the dependencies on all the associated systems.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#275

Post by FireBeyond »

ycombinatrix wrote: post #259
Tyriar wrote: post #213

Earlier quoted context omitted.

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.

Visual Studio Code was announced from day one as a lightweight development environment, not as a "text editor".

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#276

Post by Aurornis »

sbarre wrote: post #243
Aurornis wrote: post #241

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

No, I want syntax highlighting.

In the past, editors could give me syntax highlighting without opening me to vulnerabilities.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#277

Post by 6mile »

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…

Hi, I'm one of the researchers that identified this threat and I blogged about it back in November (https://opensourcemalware.com/blog/contagious-interview-vsco...)

First, @Tyriar thanks for being a part of this conversation. I know you don't have to, and I want to let you know I get that you are choosing to contribute, and I personally appreciate it.

The reality is that VS Code ships in a way that is perfect for attackers to use tasks files to compromise developers:

1. You have to click "trust this code" on every repo you open, which is just noise and desensitizes the user to the real underlying security threat. What VS Code should do is warn you when there is a tasks file, especially if there is a "command" parameter in that tasks file.

2. You can add parameters like these to tasks files to disable some of the notification features so devs never see the notifications you are talking about: "presentation": { "reveal": "never", "echo": false, "focus": false, "close": true, "panel": "dedicated", "showReuseMessage": false}

3. Regardless of Microsofts observations that opening other people's code is risky, I want to remind you that all of us open other peoples code all day long, so it seems a little duplicitous to say "you'd still be vulnerable if you trust the workspace". I mean, that's kind of our jobs. Your "Workspaces" abstraction is great on paper, especially for project based workflows, but that's not the only way that most of us use VS Code. The issue here is that Microsoft created a new feature (tasks files) that executes things when I open code in VS Code. This is new, and separate from the intrinsic risk of opening other people's code. To ignore that fact to me seems like you are running away from the responsibility to address what you've created.

Because of the above points we are quickly seeing VS Code tasks file become the number one way that developers are being compromised by nation state actors (typically North Korea/Lazarus).

Just search github and you'll see what I mean: https://github.com/search?q=path%3Atasks.json+vercel.app&ref...

There are dozens and dozens of bad guys using this technique right now. Microsoft needs to step up. End of story.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#278

Post by 12_throw_away »

alistairSH wrote: post #207
ses1984 wrote: post #168

Earlier quoted context omitted.

The point of an IDE is that it does stuff a simple text editor does not.

Sure, but as noted elsewhere, the IDEs generally don't "do stuff" by default just on opening a file folder. VSCode, by default, will run some programs as soon as you open a folder.

> the IDEs generally don't "do stuff" by default just on opening a file folder

In any JetBrains IDE: Settings > Tools > Startup Tasks.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#279

Post by siilats »

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…

How about showing the user what the ide will automatically execute upon install?

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#280

Post by jFriedensreich »

unium wrote: post #254
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?

pre alpha, xenon is like a browser framework, darc the reference browser, the vscode dev browser is like a dev focused release. https://xe.dev/darc
Post reply on HN