Rust

5960 readers

2 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

[email protected]

Credits

The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)

founded 1 year ago

MODERATORS

[email protected]

Rust Foundation Security Initiative Report (foundation.rust-lang.org)

submitted 1 year ago by [email protected] to c/[email protected]

15 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 3 points 1 year ago (2 children)

To generate the LLVM code correctly you need to run build.rs if there is any, and run proc macros which are natively compiled compiler plugins, currently running without any sandbox.

The final code isn’t run, but the build process of Cargo crates can involve running of arbitrary code.

The compilation process can be sandboxed as a whole, but if it runs arbitrary code, a malicious crate could take over the build process and falsify the LLVM output.

[–] [email protected] 1 points 1 year ago* (last edited 1 year ago) (1 children)

Hello there. Now I feel uncomfortable. Who am I to talk in the presence of experts.

To generate the LLVM code correctly you need to run build.rs if there is any

Good point.

and run proc macros which are natively compiled compiler plugins

Hmm. When I read "Given the existence of macros", I didn't really think of compiler plugins. If that's what was meant, then I apologize for what looks now like an ELI5 comment.

The compilation process can be sandboxed as a whole, but if it runs arbitrary code, a malicious crate could take over the build process and falsify the LLVM output.

Given that crater not only builds crates, but also runs tests, one would hope that such things wouldn't sneak to painter unnoticed!

[–] [email protected] 1 points 1 year ago* (last edited 1 year ago) (1 children)

Apology appreciated, but unnecessary.

I don't want to derail a useful tool. It's worth going a bit beyond "hope" as a strategy, however, and thinking about if (how) this might be exploited.

I doubt anyone will be mining crypto in your sandbox. But perhaps you should think about detection; might it be possible to mask a malicious crate with a second that attempts to detect sandboxed compilation, for instance?

In any case, I think this still looks exceedingly interesting in the typical case, which is of detecting the impact of bugs from non-malicious actors.

[–] [email protected] 1 points 1 year ago

Given the widespread existence of wasm sandboxing, rustc itself might want to think about alternative strategies for running compiler plugins. I suspect there'd be a performance hit with such an approach, but wasm tooling is getting really good; perhaps it is minor.

[–] [email protected] 1 points 1 year ago (1 children)

Hello kornel.

Assuming you have the data, do you mind sharing how many crates in their latest version use compiler plugins?

[–] [email protected] 1 points 1 year ago (1 children)

At least 69K, which is over half of all crates — https://lib.rs/quote is used almost exclusively for output of proc macros.

[–] [email protected] 1 points 1 year ago (1 children)

Oh, we are calling proc-macro crates "compiler plugins"! I didn't realize.

[–] [email protected] 1 points 1 year ago* (last edited 1 year ago) (1 children)

They are dlopened by the rustc process. You can totally mess with it: https://nitter.net/m_ou_se/status/1368632701448818691

[–] [email protected] 2 points 1 year ago

I'm aware.

I just find calling the average proc-macro crate a "compiler plugin" a little bit baffling/confusing.

Isn't the term "compiler plugin" reserved for crates/tools that depend on rustc, like clippy?