Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Using Rust Macros to exfiltrate secrets

github.com

Post reply on HN
Print view View original

41–50 of 76 posts

Re: Using Rust Macros to exfiltrate secrets

#41

Post by xfer »

terseus wrote: post #19

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…

Open it in notepad? You don't install software that automatically build your project and complain that it is doing that.

Re: Using Rust Macros to exfiltrate secrets

#42

Post by rabidferret »

the_duke wrote: post #2

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, ...) Th…

I would just like to tack on that malicious code is against the crates.io terms of service, and something like exfiltrating secrets in a build script is something that very clearly qualifies as malicious. If you ever encounter this in the wild, please make sure you report it to the crates.io team, so it can be removed.

Re: Using Rust Macros to exfiltrate secrets

#43

Post by Nullabillity »

VWWHFSfQ wrote: post #31
parhamn wrote: post #16

Earlier quoted context omitted.

Citation needed. Show me a Makefile + IDE combination that executed code by simply opening a file. I think you’re missing the language server part of this.

Does opening an android project in android studio implicitly run any of the code in the project? I'm guessing it does, because the ide seems to be very busy all the time, even when idle

build.gradle can contain arbitrary Groovy code with full system access, and needs to be executed to figure out the project structure.

Re: Using Rust Macros to exfiltrate secrets

#44

Post by Jakobeha »

terseus wrote: post #19

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…

One potential solution:

- During a session, the first time rust-toolchain encounters a proc macro it must run to analyze, it will first prompt the user and warn them.

- If the user accepts the prompt, rust-toolchain will freely run any proc macros until the next session.

- If the user rejects the prompt, that analysis will be disabled until the next session.

Similar to how VSCode and other apps handle opening links.

Re: Using Rust Macros to exfiltrate secrets

#45

Post by mjw1007 »

remram wrote: post #38
parhamn wrote: post #16

Earlier quoted context omitted.

Citation needed. Show me a Makefile + IDE combination that executed code by simply opening a file. I think you’re missing the language server part of this.

bash autocompletion will run arbitrary code from a Makefile. I wouldn't be surprised if many editors do too.

I think programmers' editors in general have treated "automatically run arbitrary code supplied by files you're editing" seriously as a security vulnerability since sometime around 2000.

(For example, Emacs realised that 'local eval' wasn't a good thing to have enabled globally in Emacs 19, in 1994, and spent the next decade or more closing many other loopholes involving local variables specified directly in files.)

If modern editors and IDEs are no longer thinking that way, I think that's a mistake.

Re: Using Rust Macros to exfiltrate secrets

#47

Post by juancampa »

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

Re: Using Rust Macros to exfiltrate secrets

#48

Post by vlovich123 »

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?

Re: Using Rust Macros to exfiltrate secrets

#49

Post by trulyme »

cogman10 wrote: post #33
parhamn wrote: post #17

Earlier quoted context omitted.

> Many other languages have the same problem (Makefiles, npm hooks, ...) This simply isn’t true. All of these require an action by a user to execute the command (e.g npm install, make build). What the author is claiming is that a typical rust LSP setup will execute the arbitrary macro code simply by viewing the file in certain IDEs. Feel free to show me an example of this in makefiles or npm and I’m happy to retract.

There aren't a bunch of languages with proc-macros and IDEs. That'd be where you'll see a major intersection. (Maybe C++ has this problem with some ides?) Languages with similar risks are ones where a Repl is is the key form of development. In those scenarios you are also one bad dependency from stolen info.

That's not really relevant though. Anything that runs code on my computer without my awareness of it should be considered a security bug.
Post reply on HN