Such a safe language, better than everything else so much so that what amounts to a linter does compiles
Arbitrary code execution during compilation – rust
21–30 of 58 posts
Re: Arbitrary code execution during compilation – rust
#22Nothing new to see here... Any of these steps could do the same to your system, and it's been the "standard" for 30+ years: ./configure make sudo make install Or literally any other language/package manager that supports build scripts.
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.
Re: Arbitrary code execution during compilation – rust
#23D 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)
Re: Arbitrary code execution during compilation – rust
#24Nothing new to see here... Any of these steps could do the same to your system, and it's been the "standard" for 30+ years: ./configure make sudo make install Or literally any other language/package manager that supports build scripts.
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.
Re: Arbitrary code execution during compilation – rust
#25Earlier 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.
"Allowing connections to http://ga1sdf4saf.ru is fine, because it's so convenient not having to put things in source control."
The database example is (largely) a solved problem. Microsoft SQL for example lets you check in an ".MDF" database file into source control. If it's a "schema only" file, it's probably just a few megabytes. It can be loaded locally without a "server" using a connection string that simply references the file name. Similar things can be done with SQL Lite, etc...
Even these approaches miss the point to a degree. Relying on an external executable is also a mistake. What if the developers update their database engine version on their laptop, and they need to go back to a previous major release branch to produce a security hotfix update? They might not be able to if the build tools have "moved on".
This is not some esoteric scenario, I'm facing this issue right now with some old SOAP endpoints where I need to rebuild the front-end that has been untouched for 10+ years, but I can't because the endpoints are HTTPS with TLS 1.0 but all new desktop and servers enforce TLS 1.2, so now I'm stuck.
The correct solution instead of the dirty shortcut is to include the WSDL file into the source code and reference it from there.
This also allows builds in cloud-hosted build platforms like GitHub Actions or Azure DevOps Pipelines, because with a hygienic build process no "LAN connectivity" is needed or assumed.
Your convenience will become someone else's security nightmare.
Re: Arbitrary code execution during compilation – rust
#26So... 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.
Re: Arbitrary code execution during compilation – rust
#27Afaik 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…
Indeed the Go build system is paying a usability price in order to guarantee that no user code is executed during builds (unless explicitly invoked e.g. via "go generate")
Re: Arbitrary code execution during compilation – rust
#28Afaik 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.…
> 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.
Re: Arbitrary code execution during compilation – rust
#29Afaik 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.…
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.
Re: Arbitrary code execution during compilation – rust
#30Earlier 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.
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 default. And turning off that default should require whoever invokes the build to explicitly grant permission to escape the sandbox.
If you need fancy things in the sandbox, put them in the sandbox.