Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Arbitrary code execution during compilation – rust

github.com

Post reply on HN
Print view View original

31–40 of 58 posts

Re: Arbitrary code execution during compilation – rust

#31

Post by moomin »

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

Suspect the same may be true of code generators in C#. It’s probably possible to do similar to Clojure as well.

Re: Arbitrary code execution during compilation – rust

#32

Post by ojkelly »

mocko wrote: post #14
winstonewert wrote: post #12

So... if I'm using a third party crate, I'm already trusting it not to do bad things in my running application. Why is it such a big deal that it could do bad things during build time just before I run it? If I'm using a third party crate... I've got to trust it one way or the other. So what's the big deal here?

In the context of a long-lived build server it could permanently compromise the machine, allowing an attacker to modify any other package you publish from there and maintain that access even after Rust has been fixed.

A lot of things could also potentially compromise a long-lived build server, to the point where it’s better not to be long lived.

If it’s not practical to use a fresh machine/vm/container/function for each build, at least rotate them out more than once a day.

You need full repeatable control over the execution environment for hermetic builds.

I also agree rust needs to either fix mitigate this. One option you have is to disable networking on the build machine.

Re: Arbitrary code execution during compilation – rust

#33

Post by stubish »

dymk wrote: post #19
jhgg wrote: post #11

Earlier quoted context omitted.

Then avoid crates that do such things. Other people however are able to make use of compile time code execution to do some pretty awesome things. For example, a database library sqlx can check all the SQL in your code as being syntactically correct, and also typed correctly against a test database at compile time. A feature that is useful and convenient for users of the library.

I agree with you and I'm not sure why you're being downvoted. That being said, it's nice to be able to have guarantees about your build without having to look at the transitive closure of dependencies in your project. It'd be nice if crates could be marked as "hygienic build" or something, and a hygienic crate can only depend on other hygienic crates. And then something like `cargo check-hygienic` which fails if any…

'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.

Re: Arbitrary code execution during compilation – rust

#34

Post by skissane »

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

> And yes, you could always put arbitrary commands in your `configure` script or your `makefile`. But those commands shouldn't be run when all you did is open the file in vi(m)/emacs.

IIRC, if I open a Gradle project in IntelliJ IDEA, it executes the Gradle build script, including any arbitrary code therein. I think many other IDEs work similarly.

Re: Arbitrary code execution during compilation – rust

#35

Post by jhgg »

amluto wrote: post #30
jhgg wrote: post #11

Earlier quoted context omitted.

Then avoid crates that do such things. Other people however are able to make use of compile time code execution to do some pretty awesome things. For example, a database library sqlx can check all the SQL in your code as being syntactically correct, and also typed correctly against a test database at compile time. A feature that is useful and convenient for users of the library.

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 generation tool. That requires the build toolchain interacting with another tool, that would "break the sandbox."

Re: Arbitrary code execution during compilation – rust

#36

Post by dureuill »

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

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

Is that true though? I think I remember that by default vscode won't enable extensions like rust analyzer when opening a folder, unless you confirm that you trust the code in that folder first. Seems like reading code from the internet to ascertain it is not malevolent is a good use case for not trusting the code.

Re: Arbitrary code execution during compilation – rust

#38

Post by typical182 »

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

Re: Arbitrary code execution during compilation – rust

#39

Post by Hello71 »

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

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

which is why before starting extensions, VS Code pops up a warning and requires you to click not just "Agree", but "Yes, I trust the authors; Trust folder and enable all features" in a dialog that also says "Code provides features that may automatically execute files in this folder.": https://code.visualstudio.com/docs/editor/workspace-trust. while I have a lot of complaints about VS Code (including, for example, last I checked they don't have such a dialog for telemetry collection), this doesn't sound like a real exploit unless the author found some way to bypass this setting.

Re: Arbitrary code execution during compilation – rust

#40

Post by camel-cdr »

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.
Post reply on HN