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

11–20 of 58 posts

Re: Arbitrary code execution during compilation – rust

#11

Post by jhgg »

jiggawatts wrote: post #10
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…

The mistake is that arbitrary transformations != arbitrary code. I want the build process to be able to generate arbitrary code based on the inputs given to it from the source control — but nothing else. No reaching out to HTTP command and control endpoints, making database calls, or deleting my home directory. It’s not just because of security. Security is a side-benefit here. The real benefit is that unrestricted b…

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.

Re: Arbitrary code execution during compilation – rust

#12

Post by winstonewert »

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?

Re: Arbitrary code execution during compilation – rust

#13

Post by jagrsw »

revelio wrote: post #3

We must start systematically sandboxing developer tools. It's scary how sensitive dev workspaces are, and how much random crap we run. After decades of training the world's parents and grandparents not to download and run programs from untrusted sources we now routinely do it ourselves.

Most reasonable companies/projects do that. I believe the compiler explorer project - https://godbolt.org/ - uses nsjail or maybe firejail for that - https://github.com/compiler-explorer/compiler-explorer/tree/...

  asm(".section .text\n"
      ".global ls\n"
      ".global le\n"
      "ls:\n"
      ".incbin \"/etc/passwd\"\n"
      "le:\n");

  int main() {
    extern char ls __asm__("ls");
    extern char le __asm__("le");
    write(1, &ls, &le - &ls);
  }

Re: Arbitrary code execution during compilation – rust

#14

Post by mocko »

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.

Re: Arbitrary code execution during compilation – rust

#15

Post by the_mitsuhiko »

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.

If that build server runs tests too the surface area of such an attack is similar.

Re: Arbitrary code execution during compilation – rust

#16

Post by the_mitsuhiko »

landr0id wrote: post #9
eleijonmarck wrote: post #4

I filed a issue on `rust-analyzer` and apparently it is by design - https://github.com/rust-lang/rust-analyzer/issues/14375

I mean it’s fairly obvious. You can do this through build.rs files as well. There was talk about trying to compile proc macros to WASM and run them sandboxed in the compiler. Not sure what happened to that RFC (by dtolnay?)

There is a POC. https://github.com/dtolnay/watt

Re: Arbitrary code execution during compilation – rust

#18

Post by tikkabhuna »

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…

Developing inside a container seems like a basic mitigation that a developer could use. Depends what you're developing though.

Re: Arbitrary code execution during compilation – rust

#19

Post by dymk »

jhgg wrote: post #11
jiggawatts wrote: post #10

Earlier quoted context omitted.

The mistake is that arbitrary transformations != arbitrary code. I want the build process to be able to generate arbitrary code based on the inputs given to it from the source control — but nothing else. No reaching out to HTTP command and control endpoints, making database calls, or deleting my home directory. It’s not just because of security. Security is a side-benefit here. The real benefit is that unrestricted b…

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 dependencies are non-hygienic.

Re: Arbitrary code execution during compilation – rust

#20

Post by Karellen »

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.

Reading code should be a safe action. If just opening and displaying code can cause your editor/IDE to perform ACE, that's a problem.

> This behavior also occurs when cargo build is run or when the application is run.

This seems like more of an afterthought. Yes, when the application is run, whatever code is in the application is run. That's kind of the point.

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.

Note that vi(m), emacs, and other editors do allow files to modify the editor's environment, e.g. with modelines, or some other more advanced systems (ctags?). But they're very careful to limit the scope of what the files can do - and haven't always got it correct and the rules have needed to be tightened a few times IIRC.

So, yeah, I think this is a real issue that probably needs addressing.

Post reply on HN