from Hacker News

Using Rust Macros to exfiltrate secrets

by superjared on 5/14/21, 2:12 PM with 75 comments

  • by the_duke on 5/14/21, 3:50 PM

    Proc macros can run arbitrary code, so this POC is not that interesting - apart from raising awareness for the problem.

    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

    Many other languages have the same (or at least similar) problem (Makefiles, npm hooks, ...)

    There is an interesting proposal and prototype for compiling proc macros to WASM so they can be run in a sandbox: https://github.com/dtolnay/watt

    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.

    Build time execution is definitely an additional attack vector.

    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.

  • by terseus on 5/14/21, 4:55 PM

    I can't believe that people is comparing opening a project in a code editor with running a build script.

    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_.

    My guess is that since the proc_macros returns a TokenStream, rust-analyzer have no way to know what it provides except running it.

    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.

  • by kam on 5/14/21, 6:00 PM

    This is why VSCode is adding Workspace Trust to prevent extensions from running untrusted code by merely opening a directory. https://github.com/microsoft/vscode/issues/120251#issuecomme...

  • by ngalstyan4 on 5/14/21, 4:08 PM

    The more general problem with trusting software supply chains is well described in Ken Thompson's Turing award lecture on "Trusting Trust"[1]

    [1]: http://users.ece.cmu.edu/~ganger/712.fall02/papers/p761-thom...

  • by Jaygles on 5/14/21, 3:53 PM

    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.

  • by vlovich123 on 5/14/21, 6:15 PM

    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?

  • by mike-cardwell on 5/14/21, 5:06 PM

  • by greenshackle2 on 5/14/21, 3:57 PM

    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.

  • by duped on 5/14/21, 4:00 PM

    For what it's worth, any VSCode extension that integrates with language tooling could be used to implement this.

  • by not2b on 5/14/21, 6:46 PM

    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).

  • by juancampa on 5/14/21, 6:14 PM

    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.

    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.

    [0] https://www.rust-lang.org/governance

  • by rhooke on 5/14/21, 6:53 PM

    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.

    I can't see a robust solution to this, though.

    [1] https://code.visualstudio.com/docs/remote/containers

  • by akkartik on 5/15/21, 1:40 AM

    Has something like this ever been possible with Common Lisp and say Emacs?

  • by cryptonector on 5/14/21, 6:22 PM

    Meh. You could do this in C also. Nothing new here.

  • by yannoninator on 5/14/21, 5:10 PM

    Blocks of text again... TL;DR?