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

11–20 of 76 posts

Re: Using Rust Macros to exfiltrate secrets

#11

Post by judofyr »

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` executable before it's enabled. It's still quite easy to click "allow" without thinking about it, but at least you'll have a choice to not execute potentially random code.

Re: Using Rust Macros to exfiltrate secrets

#12

Post by db48x »

mprovost wrote: post #7
db48x wrote: post #4

Earlier quoted context omitted.

Also, it’s not a new problem; a Makefile or configure script can run arbitrary code as well.

Yes this has always made me wonder about the pushback you see with the recent move towards curl | sh installers. In the past you'd download a random tarball and then run ./configure which could do anything.

There are three main problems with curl | sh: the file one the web server could be replaced without modifying the source in version control (and unlike a git checkout, the hash of the file is not verified), you can’t read the code before it runs, and curl could fail to download the whole file.

Of course, I bet a lot of people don’t bother to read any of the source code of a program that they’ve downloaded anyway.

Re: Using Rust Macros to exfiltrate secrets

#13

Post by db48x »

kzrdude wrote: post #10
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.

The only component is an editor that runs some code automatically. A python plugin for an editor would have the same problem - if it imports a python module for any reason, like code completion. Same problem of arbitrary code execution. I think we should work on solutions. Sandboxing both for editor plugins and for regular rust builds, should become the norm.

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 case, no sandboxing is necessary.

If your distro doesn’t enable SELinux, or your distro’s SELinux policy doesn’t protect your ssh keys, then you need to upgrade. If you don’t use Linux, then you need to upgrade to Linux.

Re: Using Rust Macros to exfiltrate secrets

#14

Post by tux3 »

db48x wrote: post #13
kzrdude wrote: post #10

Earlier quoted context omitted.

The only component is an editor that runs some code automatically. A python plugin for an editor would have the same problem - if it imports a python module for any reason, like code completion. Same problem of arbitrary code execution. I think we should work on solutions. Sandboxing both for editor plugins and for regular rust builds, should become the norm.

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…

Calling it a need to upgrade if I don't have SELinux is a little combative --- I'm perfectly happy with my AppArmor thankyouverymuch :)

Re: Using Rust Macros to exfiltrate secrets

#15

Post by mkesper »

db48x wrote: post #13
kzrdude wrote: post #10

Earlier quoted context omitted.

The only component is an editor that runs some code automatically. A python plugin for an editor would have the same problem - if it imports a python module for any reason, like code completion. Same problem of arbitrary code execution. I think we should work on solutions. Sandboxing both for editor plugins and for regular rust builds, should become the norm.

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.

Re: Using Rust Macros to exfiltrate secrets

#16

Post by parhamn »

db48x wrote: post #4
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…

Also, it’s not a new problem; a Makefile or configure script can run arbitrary code as well.

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.

Re: Using Rust Macros to exfiltrate secrets

#17

Post by parhamn »

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.

Re: Using Rust Macros to exfiltrate secrets

#18

Post by peq »

kzrdude wrote: post #10
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.

The only component is an editor that runs some code automatically. A python plugin for an editor would have the same problem - if it imports a python module for any reason, like code completion. Same problem of arbitrary code execution. I think we should work on solutions. Sandboxing both for editor plugins and for regular rust builds, should become the norm.

If I rememver correctly, the python plugin for vscode asks me whether I trust the project before running anything. At least that was the case when I last opened a Jupyter notebook in vscode.

Re: Using Rust Macros to exfiltrate secrets

#19

Post by terseus »

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.

Re: Using Rust Macros to exfiltrate secrets

#20

Post by parhamn »

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…

Agreed. The top comments on this thread are wrong, overconfident and silly. Read the article people.
Post reply on HN