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

61–70 of 76 posts

Re: Using Rust Macros to exfiltrate secrets

#61

Post by db48x »

tux3 wrote: post #14
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…

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

I’ve not used AppArmor much, but I guess it’s at least better than nothing :)

Re: Using Rust Macros to exfiltrate secrets

#62

Post by db48x »

mprovost wrote: post #26
db48x wrote: post #12

Earlier quoted context omitted.

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.

If the project uses Autoconf/Automake, then you can just read the .in files instead. If they include anything unexpected, then it will be pretty obvious (since anything unexpected will be a lot more complicated–looking than anything normal). But if they do include a bunch of custom m4 files, then you’re going to be spending more time on it than you would want.

Re: Using Rust Macros to exfiltrate secrets

#63

Post by db48x »

slimsag wrote: post #28
db48x wrote: post #12

Earlier quoted context omitted.

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…

I agree; distribution via git is better in many ways than distribution via tarball. I believe that npm and similar package managers mostly pull code from git repositories. Of course, even then you might want to double check that the package name hasn’t been hijacked or sold off.

Of course you can break the curl|sh into separate steps and check that the script isn’t malicious before you run it, but the fact that you have to do that makes it a bad idea to distribute software this way. If you were told to download an installation script, inspect it, and only then to run it then there would be less of a problem. curl|sh is yet another sign that we so often prefer convenience over reliability and safety.

Re: Using Rust Macros to exfiltrate secrets

#64

Post by tangent128 »

vlovich123 wrote: post #48

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?

rust-embed is one: https://docs.rs/rust-embed/5.9.0/rust_embed/trait.RustEmbed....

This macro lets you embed an entire folder of assets in your binary at compile time, to simplify distribution.

Taking the concept further, I could also imagine build macros that compile Typescript or SASS files at build time, or generate data structures from a Protocol Buffers definition file, or in general operations that ingest non-Rust source code and use tools outside the repository.

Re: Using Rust Macros to exfiltrate secrets

#65

Post by comex »

juancampa wrote: post #47

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 b…

Well, the topic has come up on the internals forum from time to time, e.g.:

https://internals.rust-lang.org/t/pre-rfc-procmacros-impleme...

I don’t think there’s an active working group though.

Re: Using Rust Macros to exfiltrate secrets

#67

Post by vlovich123 »

tangent128 wrote: post #64
vlovich123 wrote: post #48

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?

rust-embed is one: https://docs.rs/rust-embed/5.9.0/rust_embed/trait.RustEmbed.... This macro lets you embed an entire folder of assets in your binary at compile time, to simplify distribution. Taking the concept further, I could also imagine build macros that compile Typescript or SASS files at build time, or generate data structures from a Protocol Buffers definition file, or in general operations that ingest non-R…

Sure. I would expect such a tool to be happy enough with sandboxing to the folder containing the source of the project and the build folder, no?

Re: Using Rust Macros to exfiltrate secrets

#68

Post by banachtarski »

IshKebab wrote: post #51
judofyr wrote: post #11

Earlier quoted context omitted.

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

In a text editor....

Re: Using Rust Macros to exfiltrate secrets

#69

Post by rhencke »

banachtarski wrote: post #68
IshKebab wrote: post #51

Earlier quoted context omitted.

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?

In a text editor....

If they'd wanted you to do that, they would have named the files something like "CMakeLists.txt".

Re: Using Rust Macros to exfiltrate secrets

#70

Post by JNRowe »

remram wrote: post #36
j4yav wrote: post #23

Earlier quoted context omitted.

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

Makefiles can actually be quite dynamic, so a program merely trying to figure out the list of target has to execute code. For example put this in a Makefile and do `make `, the file will be created (no need to press enter): VALUE := $(shell touch /tmp/something)

FWIW, while both bash and fish completion execute "make -n" for tab completion that isn't the case for zsh. zsh uses an internal parser for makefiles¹, and as such won't execute the shell function or recipes that use the + prefix.

¹ https://github.com/zsh-users/zsh/blob/master/Completion/Unix...

Post reply on HN