[Feature Request] Extension Permissions, Security Sandboxing & Update Management Proposal

[PowerWeb5]

I believe that Visual Studio Code should support some kind of "Extension Permission Management", complete with prompts, warnings, opt-in, and opt-out, similar to what has been supported for some time now with Chrome, Firefox, and other browsers.

Reference Screenshot

I've provided, for reference, some screenshots showing Extension Permission and update prompts and management UIs in the below screenshot, as well as others torwards the end of this proposal.

Chrome prompting to approve additional permissions when updating an extension:

(See additional screenshots at the very bottom.)

Scope and Benefits

I have proposed, in detail here, how Extension Permissions management could function and be exposed to users, including descriptions of dialogs for prompting users to allow/deny permissions on extension install vs. updating, changes to Extensions Sidebar and Extension Details Marketplace pages, grouping/managing extensions by Category/Collection in VSCode, specific warnings and when to show them, types of permissions could define (and whether may default to opt-out or opt-in for them), APIs could provide, how extensions could operate with more limited or conditional functionality, and how could crowdsource extension safety reporting.

I'm also proposing that users can disable Auto-Update behavior for specific extensions, which, besides being useful in its own right, could allow users to stick with previous versions which require fewer permissions, manually review updates for higher-risk extensions, or avoid updating to problematic versions of extensions until issues are resolved.

Related Issues & Discussions

As discussed in Issue #9539 ("Visual Studio Code should update itself silently") regarding enabling silent, auto-updates of VSCode and Extensions) by @alexhass, @kasajian, myself and others, there are some security concerns regarding what permissions are granted to extensions when installing or updating them. As seen there, without such controls, some users aren't even comfortable installing many extensions, allowing them to auto-update once they have, or even allowing VSCode core itself to auto-update.

Proposed User Stories / Features for Extension Permissions Management

Specifically, I propose the following extension permission management features, prompts, and use cases:

1. Display Extension Permission requirements

1. Clearly labels what permissions are required by each extension in Extensions Details page, with Permission Name (plus Icon) shown underneath the Disable/Uninstall buttons for each permission required/requested.

2. Clearly label extension permissions, ideally via Icons (along with Name, Author, Description and Rating) in Extensions Sidebar (showing Installed and Available Extensions), at least as Icons next to either A) to left of # of Downloads (Cloud icon), B) to left of Settings (gear icon), or C) to right of Name and Version #, with them grayed out if denied

2. Prompt Users to Approve High-Risk Permissions

1. Notify user on extension install of potentially dangerous extension permissions and provide ability to opt-out of optional permissions or cancel install, by showing an "Approve Permissions for (ExtensionName)?" (or "Allow (ExtensionName) To?" or "Approve Extension Permissions") dialog:

   • Only show this dialog if more than just basic On-Demand Actions permissions are requested.
   • Provide VSCode options to skip this prompt if only other common, usually safe permissions as requested (like possibly "Auto-Complete"?)
   • "Approve" (or "Allow") and "Cancel Install" dialog buttons
   • Checkboxes (or toggle buttons) for each "Optional Permission" (with "(Optional") shown after permission name)
   • For Required Permissions, show Checked (but disabled, so can't modify) checkboxes shown next to required permissions, possibly with "(Required)" shown after permission name
   • [Maybe, Low Priority] If user attempts to uncheck a required permission, possibly could just suggest they "Don't install", "Disable" or "Install/Downgrade to Previous Version"

2. When Updating Extensions, show users "Approve New Permissions for (ExtensionName)?" prompt

   • Based on dialog shown when first installing
   • Only showing if/when there are new not-yet-approved permissions to review
   • Only shown if there are New Requested, New Required, or Now Required (previously optional and rejected) permissions which user hasn't already approved.
   • Show New (Not-yet-Approved or Now Required) permissions at the top
   • If permission was previously denied but is now Required instead of Optional, highlight it, and warn user may want to Cancel Update + Disable Auto-Update for that one extension instead.
   • Previously prompted permissions (whether or not previously approved, optional, required, etc.) are bottom, with space in between, so easy to review and modify here, but doesn't crowd the important changes.
   • Show dialog buttons: "Approve", "Skip Update" (only prompt again after next update), and "Never Update" (disabling auto-update).
   • [Advanced / Later / Maybe] Could ask user, after chose "Skip/Never Update", whether want to prompt again if/when required permissions change (optionally showing list of all New/Now Required permissions to check or uncheck waiting for, though may not be needed).

3. Extensions functioning with Optional Permissions denied

1. Extensions should be able to run with limited functionality when optional permissions are denied, yet be able to prompt user when try to use a feature disabled by denied permissions:

2. You could provide an API allowing extension to show the Approve Extension Permissions dialog together with a custom message (maybe even custom title too) together with API allowing extensions to check what permissions are currently approved for the extension

3. Possibly could limit extensions from checking permissions available to other extensions, in case would be security risk with them polling other extensions to find other extensions to automate/interact with as a workaround to their own denied permissions.

4. Provide "Never Ask Again" button so that a prompt is never shown again for an extension, possibly with option to disable prompts just for just a) specific feature (permission use case/prompt message), b) specific permission, or c) all permissions for this extension.

5. Can (disabled in VSCode Options) show status bar message and/or play error sound whenever attempt to use a feature (eg. hotkey, F1 action, etc.) unavailable due to denied permissions

6. Provide API making it flag an action or context menu item as requiring a permission so that will automatically show "(Disabled due to Permissions)" or "(Disabled)" after action names (eg. in F1 command line, menus, etc.), and/or show permission prompt if clicked (or hotkey is used) anyways.

4. Disable higher-risk permissions by default

1. Have dangerous permissions like Full File System Control disabled by default in permission prompts.
2. If required (vs. optional), can require user to manually check it before proceeding or warn user about the risks and how isn't needed for most extensions, and how may want to not proceed).
3. Can be based on selected "Extension Type/Category" (eg. Language Syntax, Language Syntax + Auto-Formatting, File Management, etc.)

5. Safety Reporting

1. Allow Users to Flag Extensions as Safe vs. Suspicious (in addition to Ratings / Reviews), to crowdsource security and review
2. Allowing reporting potentially malicious extensions for investigation
3. Possibly affects what, if any, type and severity of warnings are shown in Approve Permissions dialog
4. Possibly affects whether higher-risk optional permissions are enabled or disabled by default.

6. Modify Permissions Anytime

1. In Extension Sidebar, show "Enable/Disable (Permission Name) (Icon)" entry for each requested/required permission as menu items under the Gear icon (Settings menu showing Disable, Uninstall, etc. currently).
2. In Extensions Sidebar, ideally also allow clicking permission icons to enable/disable (gray out).
3. In Extensions Detail Page, allow clicking each Permission listed below the Disable, Uninstall, etc. buttons to Approve/Deny them.

7. Auto-Update options per Extension

1. Users could opt-out of Auto-Update for specific extensions, with toggle button next to Disable/Uninstall in Extensions Sidebar (under gear icon menu) and next to those buttons in Extensions Detail Page.
2. This could allow users to stick with previous versions before new high-risk permissions became required
3. This could allow avoiding updating to problematic versions of extensions until issues are resolved.
4. This could allow users to manually review/approve updates based on reviews and changelog for higher (security or reliability) risk extensions
5. This could be controlled per extension without disabling globally as may be desired by default for most extensions.
6. Can be set per extension to "Default" vs Auto-Update vs. Disable Automates, like with Firefox, with Default behavior controlled through global setting.
   Could provide Undo Update button or choose from version history (like with Chrome/Firefox extension stores) on extension details page, to enable rollback to previous version after an update causes issues, instead of just disabling until if/when ever fixed.

8. Extension Categories Enhancements

1. Extension Type Categories benefits and use cases:

   • Allow extensions to be browsed or filtered by category from within VSCode and more easily in marketplace, in addition to how are used as Collections in Marketplace currently, possibly allowing extensions to belong to multiple categories, and supporting subcategories.
   • Which permissions are selected by default in Approve Permissions dialog, and when warnings (for exceptionally high-risk, unusual permission requirements) are shown to user in that dialog can be used on the extension type.
   • This also makes it very clear to the user - without relying on them reviewing easy-to-overlook detailed permission requirements - at a glance what kind of permissions are likely to be required.
   • This can also be useful in general for helping users to find extensions, like done with Chrome and Firefox.
   • This can also make it very clear to users how advanced an extension is, with just Syntax Highlighting vs. Auto-Complete vs. Run/Debug, when trying to find an extension for a particular language.

2. Show "Extension Type/Category" near the top of the Extension Details Page:

   • Category Customizable by Author, but limited based on permissions, eg. can't classify File System control extension as "On-Demand Actions"
   • Showing this Category at either:
     A) to right of Extension Name/ID at top, in parenthesis, B) to right of Author Name, C) a separate Line below Author, D) to the left of the Permissions Names/Icons row, or E) a separate line above the Permissions row.
   • Allow Browsing and Filtering on Extensions website by Extension Type/Category

3. Group Extensions by Category in Extensions Sidebar

With grouping enabled/disabled via Icon next to "Clear Extensions Input", possibly allowing Expand/Collapse Groups, with options to group by:
- Extension Type/Category (overall, like Language Syntax, etc.)
- Permission (eg. File System, Auto-Save, Auto-Complete, On-Demand Actions), with extensions able to be shown multiple times under multiple groups.

4. Possible Additional Extension Categories / Subcategories could include

   • Language Syntax
     • Highlighting, maybe even auto-complete prompts supports (if user always chooses/confirms what to insert, vs. arbitrary, automated modification of any document contents
   • Language Syntax & Auto-Format
     • If want as separate category with much higher expected (and by-default enabled) permissions, and if don't just allow extensions belong to a couple different categories simultaneously.
   • Auto-Format (Auto Document Actions)
   • Document Tabs Management
   • Document Actions
   • Menu Extensions
   • Automation
   • File Management
   • Web-Connected

9. Specific Permission Types could include

1. On-Demand Document Actions

   • Shown in F1 command line or newly added context, etc. menu actions which the user would have to choose to perform.
   • May not need permission (or at least don't show prompt) to register these kinds of actions.

2. Automated Document Actions

   • Automate executing own (or even other built-in or other extension) actions (from F1, context menu, etc.) in response to events, timer, etc.,
   • Possibly can split into separate permission for use of other extension and/or built-in actions.

3. On-Demand Non-Document Actions

   • Automated use of VSCode features which don't just affect document contents.

4. Automated Non-Document Actions (or just "Automation")

   • Use of Actions applying to more than just document content performed automatically instead of on-demand (via context menus or F1), such as instead based on event handling, timer, etc. or in response to certain types of document edits.

5. Document Rendering (or Document/Editor Rendering/Display)

   • For custom spelling underline, indicators, showing collapsible regions, etc.

6. User Interface Extension permissions

   • Toolbar
   • Context Menu
   • Menu Bar
   • Sidebar / Tool Windows
   • Statusbar

7. File System Permissions

   • Extension Data Files
     • Maybe allow extensions full control over files in folder only they have access to (except from other extensions without full file system control) without requiring approved permissions.
   • File Browsing
     • Read/list file and folder names (and possibly sizes, timestamps, etc.) for browsing.
   • File Reading
     • Read any file on disk, including those not opened as documents by the user.
   • File Modification
     • Modify or overwrite a file.
     • Provide warning in description for this and similar permissions that this is not typically necessary for language extensions where user can choose whether to save file or whether Auto-Save Permission should be granted instead.
     • Description / Tooltip:
       Warning: This is a potential dangerous permission usually not needed for most extensions (such as most Language Syntax extensions) which, when approved, allows the extension to delete, move, rename, create, read, and modify any files or folders on your system (Instead of just those installed with it or otherwise modify contents of opened document tabs user can choose to save), so you should only enable it for extensions you trust and may want to deny this permission when optional or cancel install of extensions which don’t allow opt-out, especially if seems like this wouldn't be necessary for the type of extension.
   • File Deletion
     • Delete any existing or newly created file on disk.

8. Networking (or Internet, or Web Service Use)

9. Open Files (as Document Tabs)

10. Auto-Save (Opened Documents)

    • If needed, can possibly split into separate permissions for Open Active Document (and only if allowed by document type/extension) vs. Auto-Save All Document Tabs.

11. Manage Document Tabs

    • Reorganize, rename, save, close, or create new (but not necessarily Open Existing File as New Tab, if have that as a separate permission).

12. Create New Documents (opened as Document Tabs)

13. Task Management

14. Source Control

15. Process Control

    • Interacting with processed had launched or with existing processes.

16. Full System Control

17. Launching Processes

    • Alternative Names: "Execute" or "Run/Debug Code/App" or "Launch / Run / Debug"

    • Description: Allow to start new processes or launch applications in background, such as is often required to Run, Build, or Debug code.

    • You could possibly allow extensions requiring this or similar permissions (or provide to any extension, if/when needed) the ability to save contents of an open document with unsaved changes to a temporary file, and provide the file path to that temp file to the extension - but without providing the extension the ability to modify/overwrite that temp file by default. This would reduce risk of a malicious extension being able to save and execute arbitrary code into a temp file without that code being first shown in the opened document tab.

    • You can even, if necessary, delay any process launching until X milliseconds after any extension-automated changes (eg. auto-formatting) made to opened document contents.

    • Possibly can restrict, as defined in extension manifest and shown in Extension Details Page, what executable names are allowed. Then, at worst, the extension would have to inject malicious code into an open script document and require user

    • Possibly can restrict (without requiring separate higher-risk permission) whether any variable command line args are allowed for it other than file name and pre-declared ones to prevent passing arbitrary code via command line to execute.

    • Possibly separate permission for launching processes for exe's that are just bundled with extension vs. already installed on the system.

10. Sandboxing Extensions

What, if anything, has already been done to provide or attempt extension sandboxing or security with VSCode?

As I understand, VSCode is based on Electrum which, by design, disables much of Chromium's facility for sandboxing to enable native API access. However, Electron and Node.js both have some facilities for sandboxing and security, and there are a few projects extending support for these, as detailed below:

Electron/Node.js Sandboxing/Security References and Options to Consider

• Electron's overview of security risks and options may be a useful reference for this discussion.
• Electron's sandbox options Would these be of any help here, or anything else described in above articles?
• Here is an Issue summing up progress of sandboxing support for Electron.
• Some tips on sandboxing and security with Electron
  Might the following be useful references for implementing Sandboxing in VSCode?
• @KWEDE's Electron Sandboxing example app / templatee for Electron app using sandboxing for security:
• Great summary of sandboxing and XSS with Electron, mentioning Brave browser as having developed or contributed code to support this.
• Might enableMixedSandbox() in VSCode be applicable or use of --enable-sandbox?
• Would disabling node integration (eg. via "new BrowserWindow({ webPreferences: { nodeIntegration: false } });") and/or Preload script + WebView - as both discussed in this Atom issue, as an example (though I understand VSCode isn't based on Atom) and as also suggested at Hackernoon- help here?
• Preload script based security,

Node.js / JavaScript Sandboxing Projects

Would any of Node.js's facilities for sandboxing / security possibly be applicable here, or any of the following projects providing sandboxing for Node.js or otherwise?

• Node.js built-in VM
• VM2 (from @patriksimek, like mentioned here)
• @gf3's Sandbox
• @auth0's SandboxJS
• electron-common-ipc
• Compute's Node.js sandboxing
• Google Caja

Additional Reference Screenshots

You can see some additional good examples of Extension Permission prompts and management in the screenshots below:

Chrome prompting user to confirm higher risk permissions (and in language very clear to the user), when installing an extension:

Chrome prompting user to enable additional requested permissions when updating an extension:

Chrome allowing modifying some permissions for installed extensions, like "Allow in incognito":

Firefox allowing managing Auto-Update behavior for installed extensions:

Firefox allowing changing permissions from sidebar for installed plugins, such as to control "Ask to Activate" behavior:

Labels

Suggested additional labels for this issue:
install-update

Possible additional labels:
api-proposal, extension-host

[vscodebot]

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• Why is the deb installing keys and repositories on my system without permission? (#39544)

[PowerWeb5]

Thanks, @RMacfarlane, for tagging with suggested feature-request label.

[PowerWeb5]

Any thoughts on this proposal for Extension Permissions & Update Management, especially from those who have been involved in extension management development and discussions in the past?

CC @RMacfarlane, @roblourens, @joaomoreno, @sandy081, @egamma, @Tyriar, @bpasero, @ramya-rao-a, @octref, @alexhass, @kasajian, @mjbvz, @chrmarti, @isidorn, @IlyaBiryukov,
@FBoucher, @arhont375, @yume-chan, @gregvanl, @aeschli, @alexandrudima, @jrieken, @fabiospampinato, @chrisdias, @waderyan

[yume-chan]

1. Chrome's extension permission system is a bad design.
   "Read your data on the websites you visited", how will the extension use the data? Google only cares about the registration fee, not the safety of their users.
   Mozilla used to require you to submit the source code of your extension to be reviewed. Microsoft Store will test your app's functionality by real human.
   Many vendors except Google don't prompt user what permissions the app/extension need, they won't put the responsibility on users.

2. If you really want a permission system, the foundation of that is sandboxing. It must be possible to limit what the extension can do.
   But Code, which is based on Node.js, doesn't have such a thing.
   Extension can also depend on external components, written by any random technology.
   So the first thing to do is spending months to make a platform-dependent sandbox system with permission feature specified for Code.
   (When I'm writing this, I think running Code in a cross-platform virtual machine software is deadly simpler)

3. After you successfully limit extensions to the active work space, the goal of permission system is protecting users' sensitive data.
   Can an extension only adding commands/tasks/debug configurations be harmful?
   For an IDE, the only sensitive data is: code
   In my opinion, splitting extensions by three characteristics is enough:
   Can read file, Can write file, Can connect to network
   One more thing: Can an extension call vscode extension api without user interaction.
   Most commands are only meaningful when invoked by user, maybe we can make it a permission.

4. Update management is a good request

[PowerWeb5]

Hi @yume-chan,
Thanks for your feedback. Good points.

Though Chrome and Firefox aren't perfect when comes to notifying users of permissions, I think recently they have done a good job, and even disable extensions until user authorizes newly required permissions after an update (though without ability to reject a specific optional permission as proposed here).

In any case, Chrome and Firefox are at least a good reference as a starting place for UI and how this has been implemented (and considered critical to do so) elsewhere for extension management, though I've outlined a few ways I think this could be done a bit differently with VSCode.

Do you have any specific suggestions on other applications that allow install of extensions and require users to authorize permissions for those extensions (upon install or when new permissions are requested upon update) that you would suggest as a better reference than Chrome or Firefox?

[PowerWeb5]

@yume-chan,

Read, write, networking, and automation (VSCode command use) are the critical basic permissions to support, but I believe there are others, as can see in those proposed.

Ability to limit many code extensions to just modifying contents shown in doc tab, allowing user to control if/when those edits are saved after seeing them should suffice for many extensions. I don't want extensions able to delete folders on hard drive or connecting to internet if it's a formatting or syntax extension as is the cast for most of the many I've installed.

Other extensions which just register a new action to manually invoke on open document via F1 or context menu (as are the majority of other extensions installed, eg for formatting, deleting duplicate lines, sorting lines, etc) shouldn't be using APIs to automate messing with project files or source control or invoking save/delete commands and so forth.

[PowerWeb5]

What, if anything, has already been done to provide or attempt extension sandboxing or security with VSCode?

As I understand, VSCode is based on Electrum which, by design, disables much of Chromium's facility for sandboxing to enable native API access. However, Electron and Node.js both have some facilities for sandboxing and security, and there are a few projects extending support for these, as detailed below:

Electron/Node.js Sandboxing/Security References and Options to Consider

• Electron's overview of security risks and options may be a useful reference for this discussion.
• Electron's sandbox options Would these be of any help here, or anything else described in above articles?
• Here is an Issue summing up progress of sandboxing support for Electron.
• Some tips on sandboxing and security with Electron
  Might the following be useful references for implementing Sandboxing in VSCode?
• @KWEDE's Electron Sandboxing example app / templatee for Electron app using sandboxing for security:
• Great summary of sandboxing and XSS with Electron, mentioning Brave browser as having developed or contributed code to support this.
• Might enableMixedSandbox() in VSCode be applicable or use of --enable-sandbox?
• Would disabling node integration (eg. via "new BrowserWindow({ webPreferences: { nodeIntegration: false } });") and/or Preload script + WebView - as both discussed in this Atom issue, as an example (though I understand VSCode isn't based on Atom) and as also suggested at Hackernoon- help here?
• Preload script based security,

Node.js / JavaScript Sandboxing Projects

Would any of Node.js's facilities for sandboxing / security possibly be applicable here, or any of the following projects providing sandboxing for Node.js or otherwise?

• Node.js built-in VM
• VM2 (from @patriksimek, like mentioned here)
• @gf3's Sandbox
• @auth0's SandboxJS
• electron-common-ipc
• Compute's Node.js sandboxing
• Google Caja

[PowerWeb5]

Is this a possibility or something being considered currently?

Does anyone have any thoughts on sandboxing extensions and enabling users to manage permissions for them (or even auto-update permission, to start with)?

[PowerWeb5]

@RMacfarlane, @roblourens, @joaomoreno, @sandy081, @egamma, @Tyriar, @bpasero, or @ramya-rao-a,

Is extension security sandboxing something you would be willing to consider for VSCode?

I've provided, in my previous reply, a list of Electron and Node.js VM projects which you might be able to integrate or use as a reference for how this could be achieved with VSCode.

I've detailed in this proposal how permission management could be exposed to users, similar to how it's been done with success for Chrome and Firefox, along with other suggested enhancements for extension auto-update options, prompts, and categorization.

Though it's been a month, I haven't had any feedback from any of the VSCode developers (just one user) so any comments here would be much appreciated.

Thanks,
Dan

[PowerWeb5]

@RMacfarlane, @roblourens, @joaomoreno, @sandy081, @egamma, @Tyriar, @bpasero, or @ramya-rao-a, and other vscode devs dealing with extension management,

Any update on whether this is being considered?

As shown in links provided, there are methods and frameworks that would allow extension sandboxing even with it being based on Electron.

[damaon]

The amount of trust/review needed is insane without basic sandboxing for extensions.

I agree with @yume-chan

In my opinion, splitting extensions by three characteristics is enough:
Can read file, Can write file, Can connect to network

Are there any plans to implement it?

[phil294]

Specifically

File Reading
Read any file on disk, including those not opened as documents by the user.

is by far the most important security threat.

Please correct me if I'm wrong:
Currently, any extension I use could plant malicious code into its next update, read all my ssh keys and upload them to their server without anyone noticing for ages. Electron actually offers sandboing capabilities but they are not enforced, allowing extensions full access to node.js and my file system. This is insane. I am glad to be using it containerized. Also, strange to know how few users actually care.

[PowerWeb5]

Is VSCode extension sandboxing (for security and reliability) and extension permissions something that is being considered or can be considered by the VSCode team?

In addition to helping improve security of such extensions, sandboxing may also help improve reliability.

Potentially Preventing Current Widespread, Reoccurring Extension Host Crashing Occurring Now Across Many Extensions

This is especially important considering how frequently, especially recently, "Extension host terminated unexpectedly" has been occurring with a wide range of different extensions.

In such cases, due to lack of sandboxing or isolation, one extension will crash all other extensions.
Even worse, one extension will crash a core part of the VS Code itself, the Extension Host, and require user to manually restart it.

Worse still, such extension host crash ends up preventing even the fact that the extension host had crashed from ever getting logged, as is occurring right now for me. It also prevents the original error which caused the crash from getting logged, as well as even what extension might have caused it, as even the relevant extension activation then fails to get logged as well, it seems.

As it stands now, it is nearly impossible to identify which extension was causing the crashes. Even one-by-one disabling of extensions isn't feasible, when there 170 extensions installed, and especially when it doesn't reliably occur on every single startup (just ever few startups). Hence why I have had to put up with frequent VS Code crashes on startup for months now before identifying the extension causing them.

Reliability Benefits and Critical Fixes Possible with Extension Isolation/Sandboxing

Though IMO something should be done in the VSCode extension host implementation to reduce the frequency of such issues (as well as logging improvements/fixes to identify the extension causing the issue), sandboxing could potentially isolate extensions in a way that would prevent them from crashing all other extensions, or at least prevent them from crashing core parts of the VSCode like the extension host itself.

This could also prevent that extension from causing critical diagnostic/error logging info from not occurring, making it actually possible to identify which extension had caused the crash – even if simply by looking at which extension failed to get activated, though likely with the ability to directly report to the user the problematic extension, prompting them to disable it. VSCode could potentially even optionally auto-disable such VSCode-crash inducing extensions it if such critical crashes occur a 2nd time within a short span of time.

800+ Outstanding Issue Reports and Many (Even Official) Extensions with Frequent, Reoccurring Extension Host Crashes

Many others are reporting the same, such as my recent report (ritwickdey/vscode-live-server#285) as well as #72476, #75267, microsoft/live-share#1510, ritwickdey/vscode-live-server#285, Live Share Chat review, and 250+ other "Extension host terminated" bug reports just in the VSCode repo, 133 open issues under chrmarti/testissues and 850+ "Extension host terminated unexpectedly" bug reports across all GitHub VSCode extension repos.

A few of the extensions (including official/core/Microsoft extensions) which have frequent, reoccurring reports of causing of Extension Host Crashes include:

Live Share Audio, Live Server, Live Share Chat, Live Share, Live SASS Compiler, Typed Test, Java Language Server, and Mocha Sidebar.

And that is just based on one specific type of error that such sandboxing could potentially help address, in addition to other reliability and security benefits.

[PowerWeb5]

See #79782 for more details about proposed use of Sandboxing for Reliability (more than Security) and how it may be needed especially now in light of the many recent reoccurring issues with many different popular extensions repeatedly crashing Extension Host (and therefore all other extensions) on VSCode startup, without any way to reliably or easily workaround for many extensions, let alone determine which extensions are causing the crashes.

[marvingreenberg]

In 2019, this really should be on the list. It isn't clear there is even an obvious way to REPORT a malicious extension easily (which is it's own nontrivial problem). The permission model @PowerAccess describes is complete for an implementation, but perhaps too complex for what would be presented to a user.

Something grouping of the fine grained permissions into end-user groups like,

Access local host Network Resources (127.0.0.1, ::1)
Access global Network Resources
Execute specific command (pylint.exe,pylint)
Execute any command
Execute background processes
Access files opened by vscode
Access any files

Perhaps with a details panel that would display the detailed permissions being granted.

@yume-chan says:

  But Code, which is based on Node.js, doesn't have such a thing." (a sandbox capability).  

I understand that this is a VERY large undertaking: developing and documenting a permission model, developing or adopting a sandbox facility for node.js, and migrating all plugins. I also agree that other efforts in other domains (Chrome, Microsoft Store) are imperfect or require resources that are not appropriate for an open source undertaking like vscode. But in 2019 I fear that this is a real problem - malicious code being injected into random developer environments - that is probably already happening.

As an aside, I wanted to be able to print from vscode, I found pdconsec.vscode-print Looking at the plugin I noticed that it was internationalized to ru, fr, en which put me (reasonably?) a little on edge. I examined the plugin code and it seems benign. But then I realized there could be modifications to any of the code under node_modules, and without a package-lock.json couldn't think of any reasonable way to verify the packages under node_modules against the npm repository

[dinofx]

Both last week and ~5 months ago, our GH:E was severely impacted when a small number of users with a certain Microsoft VSCode extension installed were each issuing a large number of HTTP requests (around 1000/minute). Is there anything being considered that would limit or identify (to the developer) that an extension appears to be misbehaving? In these cases the network requests were likely due to a bug, but you could also imagine a compromised/malicious extension that is being used in a DDoS attack.

[zm-cttae]

Problem statement (Node.js security)

• Workspace trust is one thing, however IMHO full Node.js natives is a terrible thing.
• Especially problematic are filesystem or child process access.
• The level of pain and abuse that is possible is not just significant and it's a large attack vector.

Positive use cases to support

Access to the filesystem and child processes via Node.js is used and acknowledged officially, but there isn't interest yet in replacing Node.js natives and locking down extensions further.

Proposal (Node.js sandboxing system)

The moment things are locked down, all natives used to access the disk aggressively error.

These Node.js modules would be barred from ever being used, full stop:

child_process, cluster, fs

• The VS Code team needs to:
  • add an API and extension manifest entry to replace require('child_process') for linters and compilers:
    Add a sandboxed process API locked by a permissions system - c.f. child_process #174714
  • add a permissions system (extension manifest entry) for explicit whitelisting of filesystem IO:
    [security] OS-level readwrite sandboxing for filesystem readwrites #180233
  • the rest of the Node modules are honestly of limited benefit for a VS Code extension, except perhaps the nodejs http or https APIs to start a server

EDIT: whitelist os because we don't have navigator in Node.js...

[zm-cttae]

I just figured out that there is a memory leak with lit-plugin extension and I reported it here: runem/lit-analyzer#298

This ended up taking up my complete RAM in my remote VM (I develop using remote SSH) leading to the VM rendering itself unresponsive and I had to reboot the VM again.

Now, while the reason for the memory leak is an issue with the extension, my concern is that VSCode must not allow extensions for consuming such huge amounts of memory. I already discussed this here but bringing this back up again since its critical to be addressed: #127728 (comment)

In summary, this is a feature request for VSCode to allow for throttling of resources used by extensions (with limits automatically set / specified by the user) - this will avoid such issues. Thanks.

Memory leak issue reported from @tvvignesh in #175249.

This can only be possible if we implement a sandbox for running extensions.

[ghnp5]

@FBoucher - Apologies for the confusion, but what do Profiles have to do with Extension permissions?

[zm-cttae]

Agreed, also crossposting #180233 - "OS-level readwrite sandboxing for filesystem readwrites"
Its a feature request needing 20 upvotes

[FBoucher]

@ghnp5 you are right!
Apologies I was in the wrong tab! 😅

I rectified my previous message. Sorry for the confusion.

[dudicoco]

Since it doesn't seem like this is going to be fixed any time soon, does anyone have a workaround for the totally hackable and vulnerable extension system? (besides resorting to not installing extensions 😅)

[phil294]

@dudicoco You can either containerize it or block network traffic, if that's enough for you. For containerization on Linux, there are different tools available like AppArmor and Firejail or even Docker or simply setting up a new user with limited file permissions. I am using x11docker to help with the latter: sudo x11docker --dbus --hostuser a_dedicated_user_account --nxagent --backend=host --clipboard -- code this does not use Docker, but if you remove the --backend=host, you can run a docker image instead too. Edit: To clarify: this will make vscode behave isolated and you cannot access your local folders. You'll have to work in the home directory of the a_dedicated_user_account user which you must have created beforehand. Or you set up some folder permissions e.g. under /usr/local so you can share it from both users.

Regarding network blocking, there's https://github.com/evilsocket/opensnitch for Linux and Little Snitch for MacOS.

Curious to see other solutions too.

[dudicoco]

Thanks @phil294, unfortunately i'm on mac and docker is too slow due to it running on VM (slow file sync issues).

Opensnitch might be a good workaround for network traffic, what about local filesystem manipulation though? Can extensions manipulate files outside of the current vscode workspace?
Also there is the problem that extensions can modify vscode itself and modify user settings.

[k06a]

It's a shame VSCode extensions can make arbitrary damage to the host system.

[markjlorenz]

The devcontainers extension allows for both filesystem and network sandboxing. The containers provide the filesystem sandboxing, and by running DNS for the devcontainer through a pihole (setup in docker-compose), you get the network sandboxing.

.devcontainers/devcontainer.json

// For format details, see https://aka.ms/devcontainer.json. For config options, see the
// README at: https://github.com/devcontainers/templates/tree/main/src/ubuntu
{
	"name": "your_container",
	// Or use a Dockerfile or Docker Compose file. More info: https://containers.dev/guide/dockerfile
	"dockerComposeFile": "docker-compose.yml",
	"service": "devcontainer",
	"workspaceFolder": "/workspaces/your_workspace",
	
        // Features to add to the dev container. More info: https://containers.dev/features.
	"features": { },
	"customizations": {
		"vscode": {
		  "extensions": []
		}
	  },

	// Use 'forwardPorts' to make a list of ports inside the container available locally.
	// "forwardPorts": [],

	// Use 'postCreateCommand' to run commands after the container is created.
	// "postCreateCommand": "uname -a",

	// Configure tool-specific properties.
	// "customizations": {},

	// Uncomment to connect as root instead. More info: https://aka.ms/dev-containers-non-root.
	// "remoteUser": "root"
}

.devcontainers/docker-compose.yml

version: '3.8'
services:
  devcontainer:
    image: mcr.microsoft.com/devcontainers/base:jammy
    # build:
    #   context: .
    #   dockerfile: Dockerfile
    volumes:
      - ../../:/workspaces/your_workspace
    command: sleep infinity
    networks:
      your_private_network:
        ipv4_address: 192.168.1.4
    dns:
      - 192.168.1.3
    depends_on:
      - pihole

  pihole:
    container_name: pihole
    image: pihole/pihole:latest
    # For DHCP it is recommended to remove these ports and instead add: network_mode: "host"
    # network_mode: host
    hostname: pihole
    ports:
      - "8080:80/tcp" # access the pihole admin at http://localhost:8080/admin
    environment:
      TZ: 'America/New York'
      WEBPASSWORD: 'SEKRET'
    # Volumes store your data between container upgrades
    # volumes:
    #   - './etc-pihole:/etc/pihole'
    #   - './etc-dnsmasq.d:/etc/dnsmasq.d'
    #   https://github.com/pi-hole/docker-pi-hole#note-on-capabilities
    restart: unless-stopped
    networks:
      your_private_netwwork:
        ipv4_address: 192.168.1.3

networks:
  your_private_netwwork:
    driver: bridge
    ipam:
      config:
        - subnet: "192.168.1.0/24"

[marknuzz]

So, any update on this?

https://blogs.microsoft.com/blog/2024/05/03/prioritizing-security-above-all-else/

If you’re faced with the tradeoff between security and another priority, your answer is clear: Do security.
-Satya Nadella, Chairman and CEO, Microsoft

https://medium.com/@amitassaraf/2-6-exposing-malicious-extensions-shocking-statistics-from-the-vs-code-marketplace-cf88b7a7f38f

[gjsjohnmurray]

So, any update on this?

#84756 (comment)

[marcelsauer4711]

any news? https://medium.com/@amitassaraf/3-6-uncovering-design-flaws-in-the-visual-studio-code-marketplace-ea1d8e8b0171

[marknuzz]

any news? https://medium.com/@amitassaraf/3-6-uncovering-design-flaws-in-the-visual-studio-code-marketplace-ea1d8e8b0171

@marcelsauer4711 They mentioned here ETA 6 months #84756 (comment)

[feeddageek]

@marknuzz No they didn't.
The 6 months ETA is for a control mechanism for which extension can or cannot be installed.
There is no ETA for Extension permissions and sandboxing. The public roadmap only mention "exploring sandboxing scenarios" for 2023/2024

[marknuzz]

[martin12333]

@markjlorenz #52116 (comment) devcontainers

@phil294 #52116 (comment)

( I planned to use devcontainers for security sandboxing,
... but now I am very surprised by
microsoft/vscode-remote-release#6608 "Document the security model of VSCode Remote Development "
)

[yuvallevy135]

I have a question regarding vscode extensions.
I saw that 2 extension running on the same extension host.
In addition when I created 2 extension I saw that their PID is the same (probably because if the PID of the extension host).
Regarding security, if 2 extensions are running on the same process, why cant one malicious extension "steal" some important info, or access some FS that both extensions are approaching to?
Am I missing something?
I want to create some platform for creating extensions for vscode, using my extension host service, but if 2 extensions can access each other that sounds like a security problem is it?

Would love any help and explanations.

Thanks you!