Arbitrary code execution during compilation – rust • Hacker News Board

Re: Arbitrary code execution during compilation – rust

#51

Post by jiggawatts » Sun, Mar 19, 2023, 3:10 AM UTC

dymk wrote: post #46

stubish wrote: post #33

Earlier quoted context omitted.

'avoid the crates that do it' requires careful vetting of all code in the crates you use and all the crate's dependencies, now and in all future versions of your crate and crate's dependencies. Which in reality turns out to be impractical for most projects in most work environments. And even if practical, turns out that many ways of vetting the code will expand the macros and do arbitrary code execution.

> requires careful vetting of all code in the crates you use I just explained it would be useful to have a cargo sub-command for automating this

You = “You and all your coworkers, forever.”

Re: Arbitrary code execution during compilation – rust

#52

Post by jiggawatts » Sun, Mar 19, 2023, 3:11 AM UTC

jhgg wrote: post #35

amluto wrote: post #30

Earlier quoted context omitted.

As the proud owner of a production database, a test database, a duly ancient build system, etc, this is entirely wrong. It would be delightful if my build system checked my SQL against the schema that is checked in to the same repository . It should absolutely not look at my test database, nor should the test database even need to be running, thank you very much. IMO builds should be sandboxed and deterministic by de…

These are optional features. You can decide whether or not you want to use them. No one is forcing you to do these checks at compile time. My point is, the capability is useful to some people, and there are many other ways that doing arbitrary things at build/compile time can be useful or make things easier. The sqlx example is one of many. Another usage, is calling out to another tool, e.g. a protobuf code generatio…

The ability to reach .ru addresses is also convenient to some people.

Speeding down the highway as fast as possible is also convenient to some people.

Convenience becomes some else’s bad day.

Re: Arbitrary code execution during compilation – rust

#53

Post by 0atman » Sun, Mar 19, 2023, 9:06 AM UTC

This is a feature, not a bug: https://youtu.be/MWRPYBoCEaY

Re: Arbitrary code execution during compilation – rust

#54

Post by revelio » Sun, Mar 19, 2023, 9:21 AM UTC

typical182 wrote: post #38

alkonaut wrote: post #5

Afaik you don’t even need to use macros for this, can’t you just put a build.rs file in the crate and it will execute on build? Almost all build/project systems I know have this functionality simply because execution of arbitrary programs is too useful to go without. Any C# project (.csproj) for example can include a task that eats your homework. It’s scary but I don’t see a solution like sandboxing being very easy t…

FWIW, this is maybe an area where Go goes against the grain a bit and goes out of its way to not allow code you just downloaded to execute anything while you are building. For things like 'go generate', the convention is to check in the results, which means a consumer of a package has the results without executing code: https://go.dev/blog/generate

It's not that unusual. The JVM ecosystem works the same way.

Re: Arbitrary code execution during compilation – rust

#55

Post by beeb » Sun, Mar 19, 2023, 10:20 AM UTC

Longlius wrote: post #6

I would expect any sufficiently powerful macro system would have to be this way. Don't most editors ask you whether or not you want to trust some code before opening it with full privileges anyway?

Doesn't happen with helix or most terminal editors without specific config

Re: Arbitrary code execution during compilation – rust

#56

Post by GrayShade » Sun, Mar 19, 2023, 1:08 PM UTC

Karellen wrote: post #45

Grimburger wrote: post #28

Earlier quoted context omitted.

> But those commands shouldn't be run when all you did is open the file in vi(m)/emacs. How does a language server work without compiling the source? I don't see how this is rust specific at all. Just turn rustanalyzer off by default if you don't want it to run on start-up. It's one click to do so. The GP comment is completely correct, none of this needed macro expansion, it could be one line in a build.rs script.

> How does a language server work without compiling the source? That's a good point. I might suggest that for many older languages, the work of a language server didn't need to fully compile the source code to be effective. They could probably get "good enough" results with tokenisation and lexical/syntax analysis on a file-by-file basis, cross-referencing unresolved symbols with those found in other files in the sam…

> the work of a language server didn't need to fully compile the source code to be effective

And you can get that by toggling three settings in your LSP client. They're even documented in the user manual [0].

They are enabled by default because users won't be happy if their proc macros don't work. They'd be even less happy with the "ctags for Rust" approach you're suggesting.

[0] https://rust-analyzer.github.io/manual.html#security

Re: Arbitrary code execution during compilation – rust

#57

Post by Ao7bei3s » Sun, Mar 19, 2023, 9:06 PM UTC

camel-cdr wrote: post #40

WilliamBerglund wrote: post #23

D does this "the right way", which is to say free of side-effects. https://tour.dlang.org/tour/en/gems/compile-time-function-ev... https://wiki.dlang.org/Compile-time_vs._compile-time You're supposed to be able to trust the compiler, you can't trust people. ( https://forum.dlang.org/post/po2734$20mq$1@digitalmars.com )

As does C, it even guarantees that the preprocessor terminates, but it's just a tiny bit harder to write programs in the c preprocessor.

C the core language incl. preprocessor _may_ not allow arbitrary code execution during build.

But in the C ecosystem, there are no build systems with fully declarative configuration. Every project is expected to come with build configuration that is both very ad-hoc / unique to the project, and often includes tens of thousands of lines of unreadable auto-generated boilerplate (e.g. if people commit the later stages of auto-tools, which is common practice) which can run arbitrary code. So in practice C is not better at all.

Also, C still has several ways to do file inclusion from arbitrary paths, as well as ways to cause arbitrary long compile times and object size with tiny source code. Compilation time may be guaranteed to be finite, but it is certainly not bounded.

Re: Arbitrary code execution during compilation – rust

#58

Post by alkonaut » Mon, Mar 20, 2023, 12:05 PM UTC

Karellen wrote: post #20

alkonaut wrote: post #5

Afaik you don’t even need to use macros for this, can’t you just put a build.rs file in the crate and it will execute on build? Almost all build/project systems I know have this functionality simply because execution of arbitrary programs is too useful to go without. Any C# project (.csproj) for example can include a task that eats your homework. It’s scary but I don’t see a solution like sandboxing being very easy t…

I think the main problem the OP has is: > When the do_not_compile_this_code is opened in VS Code with the rust-analyzer plugin, the editor expands the some_macro!() macro. This macro reads then content of ~/.ssh/id_rsa_do_not_try_this_at_home and deletes the file. The rust-analyzer plugin seems to be the problem. It tries to compile the code when all you might want to do is read it. Like auto-executing Office macros.…

Opening code in an IDE is likely compiling the code, not merely reading it. I would not expect opening a file read only in a text editor to be certain to not execute anything. That's the reason many complex editors (including vscode) these days will ask you if you trust the contents. It's likely possible to merely "open" the code "as a text editor" would, but I'm not sure if that's what happens if you answer no.