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

171–180 of 306 posts

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#171

Post by zarzavat »

fizlebit wrote: post #59

I do feel like better application sandboxing is needed but so much open source software is built on the Unix abstraction meaning you have to run in a container, but macOS doesn’t have containers as far as I can see, and containers themselves are a bit of a poor abstraction, although maybe the best we can do with Unix at the core. I think something closer to Roblox studio would be cool where when you open an environme…

I don't think it's viable to containerize an IDE. Running user code at full permissions is a core feature for an IDE. The programs that the user develops in an IDE could potentially touch any OS surface. When the user is a developer, you have to trust them.

Though this autorun feature is crazy and should be completely off by default.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#172

Post by jasode »

mjdv wrote: post #121
echoangle wrote: post #113

Earlier quoted context omitted.

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.

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 organization and then you must go the extra step of clicking on a particular file (e.g. ".exe", ".py", ".sh") to do something dangerous.

Furthermore, in classic Visual Studio, solutions+projects are files such as ".sln" and ".vcsproj" or a "CMakeLists.txt" file.

In contrast, VSCode projects can be the folders. Folders are not just purely navigation. So "VSCode opening a folder" can act like "MS Excel opening a .xlsm file" that might have a (dangerous) macro in it. Inside the VSCode folder may have a "tasks.json" with dangerous commands in it.

Once the mental model groks the idea that a "folder" can have a special semantic meaning of "project+tasks" in VSCode, the warning messages saying "Do you trust this folder?" make more sense.

VSCode uses "folders" instead of a top-level "file" as a semantic unit because it's more flexible for multiple languages.

To re-emphasize, Windows File Explorer or macOS Finder "opening a folder" do not run "tasks.json" so it is not the same behavior as VSCode opening a folder.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#173

Post by trelane »

bilekas wrote: post #118
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.

This is so insane to me. Eclipse is... Fine for Java in the sense Visual Studio is for dotnet. But man can they both be slow. Use case depending sometimes you just need a quick editor, thats why sublime had and probably still has a huge userbase, its fast startup and flexibility. Vim, emacs and derivatives of it are the same story. I can't imagine ever opening up eclipse to edit a zig/go/js file or project. It's too…

Emacs is a full IDE, not just a quick one-off editor. Its power comes from having everything scriptable from the ground up. Contrast this with the modern Extension concept, where there is a hard line between the editor's code and any changes you might want to make to its behavior.

I think vim is probably similar, but I've not gotten into it that much.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#174

Post by trelane »

mmh0000 wrote: post #17
dfajgljsldkjag wrote: post #7

It is scary that a text editor can run hidden code just by opening a folder. We traded our safety for convenience and now we are paying the price. Users will always click the button to trust a file if they think it helps them work faster. We cannot blame them when the software design makes it so easy to make a mistake.

Tooooo be fair Vim had also had its share of execution vulnerabilities over the years. https://github.com/numirias/security/blob/master/doc/2019-06...

Was going to say the same thing about emacs: https://news.ycombinator.com/item?id=42256409

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#175

Post by direwolf20 »

trelane wrote: post #174
mmh0000 wrote: post #17

Earlier quoted context omitted.

Tooooo be fair Vim had also had its share of execution vulnerabilities over the years. https://github.com/numirias/security/blob/master/doc/2019-06...

Was going to say the same thing about emacs: https://news.ycombinator.com/item?id=42256409

What is share dot google? Here's the real link: https://news.ycombinator.com/item?id=42256409

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#176

Post by windowpains »

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.

I’ve always defaulted to no.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#177

Post by trelane »

direwolf20 wrote: post #175
trelane wrote: post #174

Earlier quoted context omitted.

Was going to say the same thing about emacs: https://news.ycombinator.com/item?id=42256409

What is share dot google? Here's the real link: https://news.ycombinator.com/item?id=42256409

Bah. It's what chrome on Android is doing now when I ask it to give me the link. Fixed it. Thanks!

I had searched for it in the search bar at the bottom of the home screen, which opened it in a chrome window. If you tap the share icon on the top right, you get the share.google link. If you tap the three dots and then something like "copy link" you get the actual link.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#178

Post by abecedarius »

echoangle wrote: post #139
duskdozer wrote: post #132

Earlier quoted context omitted.

The message isn't very clear on what exactly is allowed to happen. Just intuitively, I wouldn't have expected simply opening a folder would "automatically execute tasks" because that's strange to me

https://code.visualstudio.com/docs/editing/workspaces/worksp... It is very clear, the first sentence it that it may automatically execute code.

Thing is, when you open a webpage it's clear that it may automatically execute code (Javascript, WebAssembly). What needs to be clear (and by default limited) is the authority of that code.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#179

Post by zvqcMMV6Zcr »

sciencejerk wrote: post #39

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

Does it matter that much? I don't think there is any "safe" build system. Users will try to build project sooner or later. With Maven it is easy to add a plugin with harmful payload as dependency, you won't spot it in "source", unless you carefully review every dependency. IDEs need containers/isolation and they need it now. Instead we got that "Do you trust this project" dialog.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#180

Post by rmunn »

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

LazyVim includes a bunch of pre-configured plugins that turn NeoVim into an IDE. Fuzzy search by filename, search by text, file explorer, go to definition, go to reference... Even debugging and unit test runners, it's all there. Yet when I'm at the command line and I need to make a quick edit to one file, e.g. `nvim ~/.bashrc`, I don't pay the startup cost of waiting for 50 plugins I'm not going to use. So it's the best of both worlds.
Post reply on HN