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

21–30 of 76 posts

Re: Using Rust Macros to exfiltrate secrets

#21

Post by aseipp »

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…

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 third party binary (which I am a developer of.) That binary in turn needed its own ability to use namespacing support to sandbox applications (in a manner that works and offers enhanced security on any Linux distro, not just SELinux ones), etc. It's a non-starter.

> Since that’s generally believed to be the case, no sandboxing is necessary.

That's where you're wrong. It's necessary even if you believe it's not. It's been proven time and time again that this is the case and that the "belief" no flaws exist is wrong.

Sandboxing approaches that use techniques like namespaces, and capability security have become vastly, vastly more popular over the years on Linux, and they're going to keep getting more popular, precisely because they work where SELinux fails (that is, 98% of the running Linux systems and distros that actually exist). Browsers, WebAssembly, systems like Flatpak with "Portals" -- all of them have moved into capability-inspired and "component" sandboxing approaches, to achieve this level of security independent of the host operating system. If Chrome had decided to use SELinux instead of its own sandboxing approach, it's security model would be completely inferior to what it is today.

Re: Using Rust Macros to exfiltrate secrets

#23

Post by j4yav »

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.

Apart from running make which of course runs the makefile, under what scenario does viewing a makefile run it?

Re: Using Rust Macros to exfiltrate secrets

#24

Post by j4yav »

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.

This isn’t build time though really, which I agree is a moment you would expect to run arbitrary code. This is “edit time.”

Re: Using Rust Macros to exfiltrate secrets

#25

Post by fiddlerwoaroof »

db48x wrote: post #12
mprovost wrote: post #7

Earlier quoted context omitted.

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.

You can solve the third problem by declaring a shell function `install` that is run at the send of the script. The first problem is a problem but, as far as I know, most language package managers don’t verify provenance anyway: yarn install foo can perform arbitrary side-effects either directly or through its transitive dependencies.

Re: Using Rust Macros to exfiltrate secrets

#26

Post by mprovost »

db48x wrote: post #12
mprovost wrote: post #7

Earlier quoted context omitted.

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.

You can break the pipe and curl the file first, read it, and then run it. But I doubt that anyone ever reads through the thousands of lines of m4 that come with a typical program that uses autoconf either.

Re: Using Rust Macros to exfiltrate secrets

#28

Post by slimsag »

db48x wrote: post #12
mprovost wrote: post #7

Earlier quoted context omitted.

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.

Downloading a tarball and running ./configure from it (pretty dang common) also does not have the changes checked into version control, nor the hash verified.

Same is true of `npm install`, deb/rpm/etc packages, etc: you don't have proof what was distributed to you matches up with what was in VCS.

You can read the code before it runs and solve the "curl could fail" theoretical arguments by just.. removing `| sh` and examining + running yourself.

Re: Using Rust Macros to exfiltrate secrets

#29

Post by efaref »

j4yav wrote: post #23
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.

Apart from running make which of course runs the makefile, under what scenario does viewing a makefile run it?

You're not just viewing it. You're opening it in an IDE which compiles it behind the scenes for you.

Many IDEs also do this for other languages (e.g. by running make), and the same problem applies.

Re: Using Rust Macros to exfiltrate secrets

#30

Post by efaref »

parhamn wrote: post #16
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.

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.

IntelliJ with "Build in background" enabled?

https://www.jetbrains.com/help/idea/executing-build-file-in-...

Post reply on HN