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

41–50 of 58 posts

Re: Arbitrary code execution during compilation – rust

#41

Post by Diggsey »

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

This doesn't actually happen though. First, VS Code asks you if you trust the workspace, and only when you answer "yes" does it run rust-analyzer.

Re: Arbitrary code execution during compilation – rust

#43

Post by charrondev »

Nanana909 wrote: post #29
Karellen wrote: post #20

Earlier quoted context omitted.

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

The only way to “address” it though is individual: If you don’t want arbitrary code running on your system, you can’t use tools that require running arbitrary code.

To be clear and as many other commenters have stated, VSCode and Rust Analyzer do not require running arbitrary code to view the code with basic syntax highlighting.

When you open a directory for the first time it will pop up a bit blocking dialogue asking if you trust the authors of the contents of that of the directory to allow code execution of it.

Re: Arbitrary code execution during compilation – rust

#44

Post by speed_spread »

kalkin wrote: post #24
speed_spread wrote: post #22

Earlier quoted context omitted.

At least you had to unpack the source archive and install the dependencies yourself, which gave one time to appreciate just how much you depended on and how trusting you were. Nowadays the bad code can be in any one of your 300 auto-downloaded public unsigned dependencies. It feels light, easy and fun but it's actually powerful dark magic to summon the work of thousands of individuals into your pet project.

A makefile can run arbitrary shell commands.

Sure. And the code you're compiling will also at some point be executed. So you're trusting the persons who wrote _that_ project. Also, if a Makefile looks like it's doing anything else than setting up the compile env and building you can be sure I'm interrupting it quickly to look at what it's doing.

OTOH a declarative build manifest with transitive dependencencies is like a self-replicating invite to an open house party inside your computer. It's only a matter of time before some _bad people show up_. (cue Beastie Boys' "Fight For Your Right to Party" )

Re: Arbitrary code execution during compilation – rust

#45

Post by Karellen »

Grimburger wrote: post #28
Karellen wrote: post #20

Earlier quoted context omitted.

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

> 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 same directory (and subdirectories?), and maybe knowing something about the locations/contents of standard libraries or other system-installed libs. If the language server can't find an include file, it has the option of ignoring it, and if it comes across a symbol it can't resolve, it can just not provide any help for that symbol.

If the only "macro" expansion that's available is textual substitution (e.g. C's preprocessor), then performing that step can't do anything except provide different source code to be analysed, and is no less safe than analysing any other source code file.

Even C++'s template expansion, while Turing-complete, I don't think it's capable of performing arbitrary I/O. IIRC it's only capable of manipulating existing C++ AST fragments?

If macro expansion can execute arbitrary code though... that's a whole different ball game. It seems like the kind of thing that really should be sandboxed. Or require a specific opt-in for each new project - like the "hey, are you sure you want to run the macros in this Word doc? It may have come from an untrustworthy source." prompt (or whatever it actually says).

Edit - looking at other comments written since I started writing this reply, you do get a "are you sure you want to trust this project?" prompt. So there's that, at least.

Re: Arbitrary code execution during compilation – rust

#46

Post by dymk »

stubish wrote: post #33
dymk wrote: post #19

Earlier quoted context omitted.

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.

> 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

Re: Arbitrary code execution during compilation – rust

#48

Post by LelouBil »

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…

Isn't there an effort to use compile rust macros to wasm to sandbox them ?

Re: Arbitrary code execution during compilation – rust

#49

Post by WirelessGigabit »

I think this is actually a good case for development containers. That way you're very explicit in what you expose in the container.

It could still read your AWS keys that you pass in through the ENV though and upload those to some server in China / Russia.

Or it could delete all your source code, but that's counter productive.

Re: Arbitrary code execution during compilation – rust

#50

Post by winstonewert »

yazzku wrote: post #26
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?

You can sandbox your application when it runs, but nobody's doing much about the dev environment. If you're working for a company and using VSCode, you are often just one malicious plugin update away from leaking the company's IP and/or having your system compromised. Similar case for Python packages and such Internet-facing code environments.

Are you sandboxing your applications when you run them on your dev machine?
Post reply on HN