6 ms·

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 li

by mjdv 8mo ago

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!

andy_ppp 8mo ago
What is the stated reasoning for arbitrary code execution as a feature? Seems pretty mad to me.
- direwolf20 8mo ago
  Makefiles etc. Many types of projects use arbitrary setup and build commands or can load arbitrary plugins, and unlike VS which imposes its own project format, VSC tries to be compatible with everything that people already use. Git hooks are another one.
  - andy_ppp 8mo ago
    Please see the reply to the other comment, obviously I wasn’t explicit enough in explaining I’m talking about code execution simply by opening a directory.
    - direwolf20 8mo ago
      Some project types, such as Gradle or Maven projects, use arbitrary commands or plugins in project setup. You have to run arbitrary plugins to know which directories are the source directories, and you have to know which directories are the source directories to do anything in Java.
      - andy_ppp 8mo ago
        There’s no need to run that when opening a directory is there?
        direwolf20 8mo ago
        If you just want to see the files in the directory, then sure. But VS Code is an IDE. It's made for editing software projects which have more structure than that.
- embedding-shape 8mo ago
  Programming projects frequently feature scripts for building and packaging said projects, those have to be run somehow. Bundling running those into the editor seems like the mad part to me, but I've missed the whole VSCode train so probably something I'm missing.
  - andy_ppp 8mo ago
    The grand parent is talking about code execution can happen by just opening the directory, you’re imagining like I did (and the grandparent) that you have to run or execute something in VSC to get that to happen and I’m asking about what features could possibly require this to happen. Obviously running tests or a make file everyone understands clearly you’re executing other people’s code.
    - arzig 8mo ago
      It’s not even running tests. Test extensions usually have to run something to even populate the tests panel in my first place and provide the ability to run à la carte. Thus opening a folder will cause the test collector binary to run.
      - andy_ppp 8mo ago
        They could ask and/or parse the tests for the information rather than run them to output it. I’m honestly still not seeing a killer feature here that makes the security implications worth it!
        weaksauce 8mo ago
        yeah me as well. at least have the untrusted code allow certain plugins or certain features of plugins to run that you whitelist. not having vim keybindings or syntax highlighting is too barebones.
        WorldMaker 8mo ago
        The trouble is that "just parse the tests" isn't always an option and running arbitrary code is the nature of how software is built. The easiest example is JS testing. Most test harnesses use a JS file for configuration. If you don't know how the harness is configured how do you know you are parsing the right tests? Most test frameworks in JS use the define/it `define("some test colection", () => it("some test", () => /* …test code… */))` pattern. Tests are built as callbacks to functions. In theory, sure, you could "just" try to RegEx out the `define("name"` and `it("name"` patterns, but it becomes harder to track nesting than you think it is with just RegEx. Then you realize that because those are code callbacks, no one is stopped from building meta-test suites with things like `for (thing of someTextMatrix) { it(`handles ${thing}`, () => /* …parametric test on thing… */ }`. The test language used most in JS is JS. It's a lot harder problem than "just parsing" to figure out. In most cases a test harness needs to run the JS files to collect the full information about the test suite. Being JS files they are Turing Complete and open to doing whatever they want. Many times the test harnesses are running in a full Node environment with access to the entire filesystem and more. Most of that applies to other test harnesses in other languages as well. To get the full suite of possible tests you need to be able to build that language and run it. How much of a sandbox that language has in that case shifts, but often it is still a sandbox with ways to escape. (We've proven that there's an escape Zero Day in the Universal Turing Machine, escapes are in some ways inevitable in any and all Turing Complete languages.)
- rcxdude 8mo ago
  When you open up a folder in VS code, addons can start to set up language servers to index the code in the folder. This usually involves invoking build systems to set those up. (I think some people are fixating on the specific feature that's mentioned in the article. The reason this pop-up exists is that there are many ways that this code execution could happen. Disabling this one feature doesn't make it safe, and this feature if not present, could still be achieved by abusing other capabilities that exist in the vs code ecosystem)
- __jonas 8mo ago
  Here are some examples: - ESLint, the most commonly used linter in the JavaScript ecosystem uses a JavaScript file for configuration (eslint.config.mjs), so if you open a JS project and want your editor to show you warnings from the linter, an extension needs to run that JS - In Elixir, project configuration is written in code (mix.exs), so if you open an Elixir project and want the language server to provide you with hints (errors, warnings and such), the language server needs to execute that code to get the project configuration. More generally it will probably want to expand macros in the project, which is also code execution. - For many languages in general, in order to analyze code, editor extensions need to build the project, and this often results in code execution (like through macros or build scripts like build.rs, which I believe rust-analyzer executes)
  - andy_ppp 8mo ago
    Thanks! I think it would be better if these types of events were fine grained and you could decide if you wanted to run them the first time but I can understand them being enabled now.
    - WorldMaker 8mo ago
      More granular is more likely to train users on "Always Click Allow". The current modal dialog already has that problem and is just one O(N) dialog where N is the number of folders you open (modulo opt-outs). If you got O(N * M) of these where N is the number of folders and M is the number of tasks in tasks.json plus the number of Extensions installed that want to activate in the folder, a) you would probably go a little batty), and b) you would probably stop reading them quickly and just always click Allow. (It can also be pointed out that a lot of these are granular under the hood. In addition to Restricted Mode as a generally available sandbox, you have all sorts of workspace level controls over tasks.json and the Extensions you have installed and active for that workspace. Not to mention a robust multi-profile system where you can narrow Extensions to specific roles and moods. But most of us tend to want to fall into habits of having a "kitchen sink" profile with everything always available and don't want to think about granular security controls.)
deleted 8mo ago
[deleted]
echoangle 8mo ago
The message displayed when asking if you want to trust the directory is pretty clear about it. https://code.visualstudio.com/docs/editing/workspaces/workspace-trust https://code.visualstudio.com/docs/editing/workspaces/worksp...
- OoooooooO 8mo ago
  The message, at least for me, does not convey that merely opening may lead to code execution.
  - rcxdude 8mo ago
    Really? "May automatically execute files" suggests to me that at least code could execute without me taking any further explicit action.
  - hn-acct 8mo ago
    Other IDEs do this too btw
- CjHuber 8mo ago
  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,
  - ses1984 8mo ago
    The point of an IDE is that it does stuff a simple text editor does not.
    - alistairSH 8mo ago
      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.
jasode 8mo ago
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.
- deleted 8mo ago
  [deleted]
- EGreg 8mo ago
  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-from-macro-viruses-a3f3576a-bfef-4d25-84dc-70d18bde5903 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 https://www.youtube.com/watch?v=XPogdNafgic

by mjdv 8mo ago

andy_ppp 8mo ago

What is the stated reasoning for arbitrary code execution as a feature? Seems pretty mad to me.

direwolf20 8mo ago
Makefiles etc. Many types of projects use arbitrary setup and build commands or can load arbitrary plugins, and unlike VS which imposes its own project format, VSC tries to be compatible with everything that people already use. Git hooks are another one.
- andy_ppp 8mo ago
  Please see the reply to the other comment, obviously I wasn’t explicit enough in explaining I’m talking about code execution simply by opening a directory.
  - direwolf20 8mo ago
    Some project types, such as Gradle or Maven projects, use arbitrary commands or plugins in project setup. You have to run arbitrary plugins to know which directories are the source directories, and you have to know which directories are the source directories to do anything in Java.
    - andy_ppp 8mo ago
      There’s no need to run that when opening a directory is there?
      - direwolf20 8mo ago
        If you just want to see the files in the directory, then sure. But VS Code is an IDE. It's made for editing software projects which have more structure than that.
embedding-shape 8mo ago
Programming projects frequently feature scripts for building and packaging said projects, those have to be run somehow. Bundling running those into the editor seems like the mad part to me, but I've missed the whole VSCode train so probably something I'm missing.
- andy_ppp 8mo ago
  The grand parent is talking about code execution can happen by just opening the directory, you’re imagining like I did (and the grandparent) that you have to run or execute something in VSC to get that to happen and I’m asking about what features could possibly require this to happen. Obviously running tests or a make file everyone understands clearly you’re executing other people’s code.
  - arzig 8mo ago
    It’s not even running tests. Test extensions usually have to run something to even populate the tests panel in my first place and provide the ability to run à la carte. Thus opening a folder will cause the test collector binary to run.
    - andy_ppp 8mo ago
      They could ask and/or parse the tests for the information rather than run them to output it. I’m honestly still not seeing a killer feature here that makes the security implications worth it!
      - weaksauce 8mo ago
        yeah me as well. at least have the untrusted code allow certain plugins or certain features of plugins to run that you whitelist. not having vim keybindings or syntax highlighting is too barebones.
      - WorldMaker 8mo ago
        The trouble is that "just parse the tests" isn't always an option and running arbitrary code is the nature of how software is built. The easiest example is JS testing. Most test harnesses use a JS file for configuration. If you don't know how the harness is configured how do you know you are parsing the right tests? Most test frameworks in JS use the define/it `define("some test colection", () => it("some test", () => /* …test code… */))` pattern. Tests are built as callbacks to functions. In theory, sure, you could "just" try to RegEx out the `define("name"` and `it("name"` patterns, but it becomes harder to track nesting than you think it is with just RegEx. Then you realize that because those are code callbacks, no one is stopped from building meta-test suites with things like `for (thing of someTextMatrix) { it(`handles ${thing}`, () => /* …parametric test on thing… */ }`. The test language used most in JS is JS. It's a lot harder problem than "just parsing" to figure out. In most cases a test harness needs to run the JS files to collect the full information about the test suite. Being JS files they are Turing Complete and open to doing whatever they want. Many times the test harnesses are running in a full Node environment with access to the entire filesystem and more. Most of that applies to other test harnesses in other languages as well. To get the full suite of possible tests you need to be able to build that language and run it. How much of a sandbox that language has in that case shifts, but often it is still a sandbox with ways to escape. (We've proven that there's an escape Zero Day in the Universal Turing Machine, escapes are in some ways inevitable in any and all Turing Complete languages.)
rcxdude 8mo ago
When you open up a folder in VS code, addons can start to set up language servers to index the code in the folder. This usually involves invoking build systems to set those up. (I think some people are fixating on the specific feature that's mentioned in the article. The reason this pop-up exists is that there are many ways that this code execution could happen. Disabling this one feature doesn't make it safe, and this feature if not present, could still be achieved by abusing other capabilities that exist in the vs code ecosystem)
__jonas 8mo ago
Here are some examples: - ESLint, the most commonly used linter in the JavaScript ecosystem uses a JavaScript file for configuration (eslint.config.mjs), so if you open a JS project and want your editor to show you warnings from the linter, an extension needs to run that JS - In Elixir, project configuration is written in code (mix.exs), so if you open an Elixir project and want the language server to provide you with hints (errors, warnings and such), the language server needs to execute that code to get the project configuration. More generally it will probably want to expand macros in the project, which is also code execution. - For many languages in general, in order to analyze code, editor extensions need to build the project, and this often results in code execution (like through macros or build scripts like build.rs, which I believe rust-analyzer executes)
- andy_ppp 8mo ago
  Thanks! I think it would be better if these types of events were fine grained and you could decide if you wanted to run them the first time but I can understand them being enabled now.
  - WorldMaker 8mo ago
    More granular is more likely to train users on "Always Click Allow". The current modal dialog already has that problem and is just one O(N) dialog where N is the number of folders you open (modulo opt-outs). If you got O(N * M) of these where N is the number of folders and M is the number of tasks in tasks.json plus the number of Extensions installed that want to activate in the folder, a) you would probably go a little batty), and b) you would probably stop reading them quickly and just always click Allow. (It can also be pointed out that a lot of these are granular under the hood. In addition to Restricted Mode as a generally available sandbox, you have all sorts of workspace level controls over tasks.json and the Extensions you have installed and active for that workspace. Not to mention a robust multi-profile system where you can narrow Extensions to specific roles and moods. But most of us tend to want to fall into habits of having a "kitchen sink" profile with everything always available and don't want to think about granular security controls.)

deleted 8mo ago

[deleted]

echoangle 8mo ago

The message displayed when asking if you want to trust the directory is pretty clear about it. https://code.visualstudio.com/docs/editing/workspaces/workspace-trust https://code.visualstudio.com/docs/editing/workspaces/worksp...

OoooooooO 8mo ago
The message, at least for me, does not convey that merely opening may lead to code execution.
- rcxdude 8mo ago
  Really? "May automatically execute files" suggests to me that at least code could execute without me taking any further explicit action.
- hn-acct 8mo ago
  Other IDEs do this too btw
CjHuber 8mo ago
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,
- ses1984 8mo ago
  The point of an IDE is that it does stuff a simple text editor does not.
  - alistairSH 8mo ago
    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.

jasode 8mo ago

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.

deleted 8mo ago
[deleted]
EGreg 8mo ago
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-from-macro-viruses-a3f3576a-bfef-4d25-84dc-70d18bde5903 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 https://www.youtube.com/watch?v=XPogdNafgic