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

51–60 of 76 posts

Re: Using Rust Macros to exfiltrate secrets

#51

Post by IshKebab »

judofyr wrote: post #11
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…

> 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. The difference here is that it happens when you open the project in the editor . If I'm suspicious of some code my first reaction would be to open it my editor and inspect it. The ESLint extension always asks whether you trust the `eslint` executab…

That's a really recent feature and I'm sure Rust-analyzer will support it soon.

I suspect the same problem exists in many other languages. How can you open a CMake project without executing it?

Re: Using Rust Macros to exfiltrate secrets

#52

Post by not2b »

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

Re: Using Rust Macros to exfiltrate secrets

#53

Post by not2b »

duped wrote: post #6
Jaygles wrote: post #3

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.

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.

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

Re: Using Rust Macros to exfiltrate secrets

#54

Post by rhooke »

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

Re: Using Rust Macros to exfiltrate secrets

#55

Post by foepys »

parhamn wrote: post #17
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…

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

Visual Studio has the same problem with C#. By default VS will load all defined analyzers into Roslyn which can execute arbitrary code.

VS warns you with a confirmation dialog that shouldn't just be ignored because "I just want to look and not compile". So, don't open any random .csproj or .sln and assume you are safe.

Re: Using Rust Macros to exfiltrate secrets

#56

Post by bluejekyll »

rabidferret wrote: post #42
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.

I think it would be better to report here, https://rustsec.org/, and folks running cargo audit would be aware of the issue even if they’ve already downloaded the dependency.

Re: Using Rust Macros to exfiltrate secrets

#57

Post by tialaramex »

trulyme wrote: post #49
cogman10 wrote: post #33

Earlier quoted context omitted.

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.

Alas, the nature of computation makes this only ever a matter of squinting hard enough at the problem.

Just as it turns out that matter and energy are almost the same thing seen from a different point of view, it's the same with code and data. Running code and processing data are no different to a computer.

You think a picture of a dog and a Windows program are plainly different kinds of things, the computer does not agree.

Something like Wuffs † aims to at least control the blast radius. If (in some alternate or far future world) you were only ever looking at pictures of a dog via Wuffs, you could at least feel confident that doing so did not have some entirely unforeseen consequences, like exfiltrating your SSH private keys. Today you certainly can't be sure of that, none of the tools you use have such a cautious approach.

† https://github.com/google/wuffs

Re: Using Rust Macros to exfiltrate secrets

#58

Post by greenshackle2 »

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…

By default rust-analyzer also executes Rust build scripts (build.rs) just by opening the project in an IDE, so as far as Rust goes the comparison is apt.

    rust-analyzer.cargo.runBuildScripts (default: true)

    Run build scripts (build.rs) for more precise code analysis.
https://rust-analyzer.github.io/manual.html

Re: Using Rust Macros to exfiltrate secrets

#59

Post by db48x »

aseipp wrote: post #21
db48x wrote: post #13

Earlier quoted context omitted.

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…

SELinux is nothing but a maintenance burden for developers and users. There's a reason no major distro beyond the Fedora line that enables it by default, including the one I work one; it almost invariably frustrates users, has incomplete support for the workflows they use, and so they turn it off anyway. I literally turned off SELinux on my new ARM64 Fedora machine last week, because it prevented me from installing a…

Don’t confuse the sandboxing a browser does with other types. I would never argue that a browser shouldn’t sandbox javascript. The kernel should also prevent the browser from reading your SSH keys as well, just in case :)

Re: Using Rust Macros to exfiltrate secrets

#60

Post by db48x »

mkesper wrote: post #15
db48x wrote: post #13

Earlier quoted context omitted.

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…

We use SELinux at work. It's really a lot of work to check all requests whether they're legitimate or not.

No argument there. The one downside of any fine–grained security system is the work it takes to build and maintain the security policy.
Post reply on HN