Proc macros can run arbitrary code, so this POC is not that interesting - apart from raising awareness for the problem.<p>This can be done even easier without users having to use a macro: with `build.rs` build scripts, which are run by default. So all you'd need is to compromise some popular dependency with a custom build.rs<p>Many other languages have the same (or at least similar) problem (Makefiles, npm hooks, ...)<p>There is an interesting proposal and prototype for compiling proc macros to WASM so they can be run in a sandbox: <a href="https://github.com/dtolnay/watt" rel="nofollow">https://github.com/dtolnay/watt</a><p>But in the end it doesn't make that much difference: nothing prevents a random library from just reading your secrets and calling curl to send it to a server at runtime.<p>Build time execution is definitely an additional attack vector.<p>But if you use a third party dependency, you have to trust it or review all it's code for every version. There is no way around this, and it's true for any language.
I can't believe that people is comparing opening a project in a code editor with running a build script.<p>The PoC doesn't even open a file, it just opens the directory. It's a pretty big difference, when you execute a build script you _expect_ to run code, when you open a directory in your editor you don't expect any side effect _at all_.<p>My guess is that since the proc_macros returns a TokenStream, rust-analyzer have no way to know what it provides except running it.<p>I'm not sure there's a solution for this that doesn't cripple macros in Rust, apart from being able to configure rust-analyzer to ignore the macros, which clearly limit its usefulness.
This is why VSCode is adding Workspace Trust to prevent extensions from running untrusted code by merely opening a directory.
<a href="https://github.com/microsoft/vscode/issues/120251#issuecomment-825832603" rel="nofollow">https://github.com/microsoft/vscode/issues/120251#issuecomme...</a>
The more general problem with trusting software supply chains is well described in Ken Thompson's Turing award lecture on "Trusting Trust"[1]<p>[1]: <a href="http://users.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf" rel="nofollow">http://users.ece.cmu.edu/~ganger/712.fall02/papers/p761-thom...</a>
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.
Is there a reason that access to the filesystem isn't sandboxed aggressively by the compiler? Even having build macros that can access arbitrary parts of the filesystem (vs a dedicated scratch directory) seems like a bad idea. Is there any legitimate use-case here?
This doesn't affect me because I <a href="https://www.grepular.com/Sandbox_Rust_Development_with_Rust_Analyzer" rel="nofollow">https://www.grepular.com/Sandbox_Rust_Development_with_Rust_...</a>
You can also just put arbitrary code in build.rs, it will be run by cargo check, rust-analyzer, etc. Though I admit macro expansion hacks are more fun and easier to hide.
This issue is very similar to the problem of malicious macros in Microsoft Office documents, and I think it needs to be addressed somehow (by figuring out a proper security model and asking for user confirmation for actions outside this model).
Are there any working groups or teams in the rust foundation[0] looking into stuff like this? I know every package manager has these issues but there's no technical reason preventing us from building sandboxes (i.e. WASM, deno, ...) for this and making it a first class citizen of cargo/rustup/etc.<p>Just installing a relatively popular crate (say Hyper) makes you realize that all of your secret could have been stolen by any of the myriad of dependencies.<p>[0] <a href="https://www.rust-lang.org/governance" rel="nofollow">https://www.rust-lang.org/governance</a>
A lot of the work I do recently has been using devcontainers in VSCode [1]. They even have a Rust sample one. I feel like this would provide at least a little bit of protection against this kind of attack if you do not mount any imporant stuff into the container.<p>I can't see a robust solution to this, though.<p>[1] <a href="https://code.visualstudio.com/docs/remote/containers" rel="nofollow">https://code.visualstudio.com/docs/remote/containers</a>