[HN Gopher] Arbitrary code execution during compilation - rust
       ___________________________________________________________________
        
       Arbitrary code execution during compilation - rust
        
       Author : eleijonmarck
       Score  : 20 points
       Date   : 2023-03-18 21:45 UTC (1 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | eleijonmarck wrote:
       | POC to demonstrate how to delete files when cargo build runs
        
       | winstonewert wrote:
       | 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?
        
         | mocko wrote:
         | 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.
        
           | the_mitsuhiko wrote:
           | If that build server runs tests too the surface area of such
           | an attack is similar.
        
       | revelio wrote:
       | 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.
        
         | jagrsw wrote:
         | 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/...                 int main()
         | {        asm(".incbin \"/etc/passwd\"\n")       }
        
       | eleijonmarck wrote:
       | I filed a issue on `rust-analyzer` and apparently it is by design
       | - https://github.com/rust-lang/rust-analyzer/issues/14375
        
         | landr0id wrote:
         | 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?)
        
       | alkonaut wrote:
       | 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 to retrofit either.
        
         | jiggawatts wrote:
         | 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 build processes cannot be
         | versioned with source control. If the build process can "reach
         | out" and pull in data from external sources, then it will
         | always use the "latest" version, not the version in that branch
         | or commit.
         | 
         | It's about being hygienic.
        
           | jhgg wrote:
           | 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.
        
       | Longlius wrote:
       | 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?
        
         | landr0id wrote:
         | Yes, which was kind of a result of people making a fuss about
         | this a year or two ago iirc.
        
       | proctrap wrote:
       | Old, it's not new that macro expansions, build files and build
       | tooling can do that. (And if we sandboxed that, you still get
       | infected release builds, check your deps..)
       | 
       | See NPM installations and "please sponsor this project" messages,
       | which can also give you a virus.
        
       ___________________________________________________________________
       (page generated 2023-03-18 23:00 UTC)