Arbitrary code execution during compile from `rust-analyzer`
eleijonmarck opened this issue · 9 comments
Arbitrary Code Execution During Rust Compilation
I recently played around with rust macros and discovered that they allow for arbitrary code execution during compilation. A proof-of-concept demonstrates a critical vulnerability in the Rust programming language ecosystem. The proof-of-concept, called do not-run-this-code, abuses Rust macros to interact with and modify the machine on which the Rust code is being compiled.
Github: https://github.com/eleijonmarck/do-not-compile-this-code
rust-analyzer version: v0.3.1435
rustc version:
% rustc --version
rustc 1.64.0 (a55dd71d5 2022-09-19)
That's by design and documented in https://rust-analyzer.github.io/manual.html#security.
interesting choice. so it means any crate that I download could execute any code on my machine? 🤔
Any crate you use can execute code on your computer, either at compile-time or at run-time.
run-time is expected for me. but during compile-time? 🤔
Compile-time is by design too, and not too different from, say, a CMake script or a npm post-install step.
Avoiding this requires changes in rustc to allow sandboxing proc macros using eg wasm, in cargo to sandbox build scripts and in rustup to disable path toolchain specifications in rust-toolchain.toml. All of these can only be done on an opt-in basis due to backward compatibility reasons and especially for proc macros and build scripts the sandboxing will need to be very configurable. There are many (ab)uses of them out in the wild for everything from build scripts running a C compiler to proc macros querying a database to check at compile time if sql queries are correct. Fully sandboxing would break all these use cases. Only the rustup change can be done with limited impact. At the very least I have never actually seen a use of path toolchain specifications. We also want to sandbox proc macros for determinism and security, but it has to be opt-in.
By the way if you use vscode, the rust-analyzer extension won't start unless you marked the workspace as trusted for this exact reason. It is expected that you can cause arbitrary code execution in workspaces marked as trusted.
Currently the only way to solve this, is by using bubblewrap, but it can be bypassed via .cargo/config and rust-toolchain.toml.
You could bubblewrap rust-analyzer itself I guess. The extension allows overriding the server path. You have to make sure that the .vscode/settings.json in the repo doesn't override the server path to a non-bubblewrapped version though...
Closing, as this is by design, and we can't improve anything on our own. The users will value convenience more than security in the corner case when you want to browse code, but absolutely never run it.
Most people who are reasonably familiar with the language will be aware of this issue, it's documented in our manual, and we respect Code's Trusted workspaces feature by disabling the extension in untrusted projects. Keep in mind that other languages and build systems have similar features.