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

221–230 of 306 posts

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#221

Post by ecshafer »

eikenberry wrote: post #6
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.

Seems very odd to me that someplace would force the use of a particular development tool. I've seen it only one time while interviewing, where they wanted everyone to have identical setups so they could easily hop onto each others computers when needed... it was weird and I took it as a red flag and didn't follow through them them.

If you code in embedded systems or FPGA its very common since you are using very specific vendor tools. A lot of enterprise companies have a "one way" kind of philosophy as well, they lock down the systems so much "for security" that you might not be able to install anything other than Eclipse or whatever is approved.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#222

Post by Tyriar »

PunchyHamster wrote: post #215
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…

AI certainly made everything in this area more complicated. I 100% agree about sandboxing and we have people investing in this right now, there's an early opt-in version we just landed recently in Insiders.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#223

Post by Tyriar »

CWuestefeld wrote: post #216
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…

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

Good point about one off edits and logs, thanks for all the insights. I'll pass these discussions on to the feature owner!

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#224

Post by nacs »

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…

Thanks for being part of the discussion. Almost every response from you in this thread however comes off an unyielding, "we decided this and it's 100% right"?

In light of this vulnerability, the team may want to revisit some of these assumptions made.

I guarantee the majority of people see a giant modal covering what they're trying to do and just do whatever gets rid of it - ie: the titlebar that says 'Trust this workspace?' and hit the big blue "Yes" button to quickly just get to work.

With AI and agents, there are now a lot of non-dev "casual" users using VS code because they saw something on a Youtube video too that have no clue what dangers they could face just by opening a new project.

Almost noone is going to read some general warning about how it "may" execute code. At the very least, scan the project folder and mention what will be executed (if it contains anything).

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#225

Post by jFriedensreich »

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 running as user account on a bare machine can be secure not even thinking about agents in the mix. We are working on a custom browser called darc based on chromium IWAs and controlled frames instead of electron and optimised for this. (apache 2.0)

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#226

Post by tclancy »

Muromec wrote: post #116
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?

Sounds like autorun on usb drives all over again. They cant learn

I think that's a bit ungenerous: there is a push and pull between security and seamless user experience and it's never obvious where the line should be set. You really only figure out which way to move it after someone complains.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#227

Post by CjHuber »

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 find this reply concerning. If its THE security feature, then why is "Trust" a glowing bright blue button in a popup that pop up at the startup forcing a decision. That makes no sense at all. Why not a banner with the option to enable those features when needed like Office tools have.

Also the two buttons have the subtexts of either "Browse folder in restricted mode" or "Trust folder and enable all features", that is quite steering and sounds almost like you cannot even edit code in the restricted mode.

"If you don't trust the authors of these files, we recommend to continue in restricted mode" also doesn't sound that criticial, does it?

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#228

Post by Tyriar »

nacs wrote: post #224
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…

Thanks for being part of the discussion. Almost every response from you in this thread however comes off an unyielding, "we decided this and it's 100% right"? In light of this vulnerability, the team may want to revisit some of these assumptions made. I guarantee the majority of people see a giant modal covering what they're trying to do and just do whatever gets rid of it - ie: the titlebar that says 'Trust this wor…

Didn't mean to come off that way, I know a lot of the decisions that were made. One thing I've got from this is we should probably open `/tmp/`, `C:\`, ~/`, etc. in restricted mode without asking the user. But a lot of the solutions proposed like opening everything in restricted mode I highly doubt would ever happen as it would further confusion, be a big change to UX and so on.

With AI the warning needs to appear somewhere, the user would ignore it when opening the folder, or ignore the warning when engaging with agent mode.

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#229

Post by jlarocco »

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…

[flagged]

Re: Threat actors expand abuse of Microsoft Visual Studio Code

#230

Post by ablob »

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…

So why not allow for enabling this behavior as a configuration option? A big fat banner for most users (i.e. by default) and the few edge cases get the status bar entry after they asked for it.
Post reply on HN