5 ms·

This is a huge deal right? VSCode has to be one of the most popular editors and the standard way of setting up the Rust toolchain on a machine would get you in

This is a huge deal right? VSCode has to be one of the most popular editors and the standard way of setting up the Rust toolchain on a machine would get you in a state that makes you vulnerable to this.

duped 5y ago
This is as huge a deal as "using ./configure && make install to exfiltrate secrets." It's a class of supply chain attack focusing on build time code evaluation. Almost every programming language has some kind of support for arbitrary code execution at build time, and any project of scale is going to require it. RCE isn't an interesting exploit when the system is literally designed to run code from somewhere else.
- j4yav 5y ago
  This isn’t build time though really, which I agree is a moment you would expect to run arbitrary code. This is “edit time.”
  - duped 5y ago
    It is build time. Whether rust-analyzer should run build-time code at initialization is a different discussion.
    - j4yav 5y ago
      That is a more philosophical definition of build time than what I am referring to.
      - duped 5y ago
        It's not philosophical, it is literal. Rust macros and build.rs require build commands to be executed by the rust compiler (cargo check, for example). These are third party tools that have been implemented to execute build commands during initialization. It's not an issue with Rust, it's an issue with the implementation of the language client and text editor allowing the client to initialize when opening a workspace.
        j4yav 5y ago
        What I mean is that my definition of build time is more things that happen when you are running a build. If you do build time things at other times then I don’t personally consider them build time activities any more. You have converted your build time activities into something more general at that point. They may be spiritually or metaphorically still build steps in some sense, but they are happening outside that context.
- not2b 5y ago
  No, it's worse. People will have very different expectations. Running 'make install' especially as root implies a high level of trust, so users will be appropriately cautious. Users won't expect that simply opening code in an editor will be similarly risky (though it's similar to malicious Word and Excel macros, Office now disables those by default for documents coming from an untrusted source, like via email).
kzrdude 5y ago
The only component is an editor that runs some code automatically. A python plugin for an editor would have the same problem - if it imports a python module for any reason, like code completion. Same problem of arbitrary code execution. I think we should work on solutions. Sandboxing both for editor plugins and for regular rust builds, should become the norm.
- db48x 5y ago
  Sandboxing isn’t necessary. Proper use of SELinux, which the Linux kernel in your computer already supports even if your distro doesn’t enable it, would already prevent any process other than ssh from reading your private key. The build system could run ssh and ssh would be allowed to read the key, but the key is still safe as long as ssh cannot be tricked into revealing it. Since that’s generally believed to be the case, no sandboxing is necessary. If your distro doesn’t enable SELinux, or your distro’s SELinux policy doesn’t protect your ssh keys, then you need to upgrade. If you don’t use Linux, then you need to upgrade to Linux.
  - tux3 5y ago
    Calling it a need to upgrade if I don't have SELinux is a little combative --- I'm perfectly happy with my AppArmor thankyouverymuch :)
    - db48x 5y ago
      I’ve not used AppArmor much, but I guess it’s at least better than nothing :)
  - mkesper 5y ago
    We use SELinux at work. It's really a lot of work to check all requests whether they're legitimate or not.
    - db48x 5y ago
      No argument there. The one downside of any fine–grained security system is the work it takes to build and maintain the security policy.
iudqnolq 5y ago
It requires never actually running the program to be worse than the status quo in any language. If you run code it's trivially a code execution.

duped 5y ago

This is as huge a deal as "using ./configure && make install to exfiltrate secrets." It's a class of supply chain attack focusing on build time code evaluation. Almost every programming language has some kind of support for arbitrary code execution at build time, and any project of scale is going to require it. RCE isn't an interesting exploit when the system is literally designed to run code from somewhere else.

j4yav 5y ago
This isn’t build time though really, which I agree is a moment you would expect to run arbitrary code. This is “edit time.”
- duped 5y ago
  It is build time. Whether rust-analyzer should run build-time code at initialization is a different discussion.
  - j4yav 5y ago
    That is a more philosophical definition of build time than what I am referring to.
    - duped 5y ago
      It's not philosophical, it is literal. Rust macros and build.rs require build commands to be executed by the rust compiler (cargo check, for example). These are third party tools that have been implemented to execute build commands during initialization. It's not an issue with Rust, it's an issue with the implementation of the language client and text editor allowing the client to initialize when opening a workspace.
      - j4yav 5y ago
        What I mean is that my definition of build time is more things that happen when you are running a build. If you do build time things at other times then I don’t personally consider them build time activities any more. You have converted your build time activities into something more general at that point. They may be spiritually or metaphorically still build steps in some sense, but they are happening outside that context.
not2b 5y ago
No, it's worse. People will have very different expectations. Running 'make install' especially as root implies a high level of trust, so users will be appropriately cautious. Users won't expect that simply opening code in an editor will be similarly risky (though it's similar to malicious Word and Excel macros, Office now disables those by default for documents coming from an untrusted source, like via email).

kzrdude 5y ago

The only component is an editor that runs some code automatically. A python plugin for an editor would have the same problem - if it imports a python module for any reason, like code completion. Same problem of arbitrary code execution. I think we should work on solutions. Sandboxing both for editor plugins and for regular rust builds, should become the norm.

db48x 5y ago
Sandboxing isn’t necessary. Proper use of SELinux, which the Linux kernel in your computer already supports even if your distro doesn’t enable it, would already prevent any process other than ssh from reading your private key. The build system could run ssh and ssh would be allowed to read the key, but the key is still safe as long as ssh cannot be tricked into revealing it. Since that’s generally believed to be the case, no sandboxing is necessary. If your distro doesn’t enable SELinux, or your distro’s SELinux policy doesn’t protect your ssh keys, then you need to upgrade. If you don’t use Linux, then you need to upgrade to Linux.
- tux3 5y ago
  Calling it a need to upgrade if I don't have SELinux is a little combative --- I'm perfectly happy with my AppArmor thankyouverymuch :)
  - db48x 5y ago
    I’ve not used AppArmor much, but I guess it’s at least better than nothing :)
- mkesper 5y ago
  We use SELinux at work. It's really a lot of work to check all requests whether they're legitimate or not.
  - db48x 5y ago
    No argument there. The one downside of any fine–grained security system is the work it takes to build and maintain the security policy.

iudqnolq 5y ago

It requires never actually running the program to be worse than the status quo in any language. If you run code it's trivially a code execution.