Comment by codedokode

Comment by codedokode 6 days ago

18 replies

View on Hacker News

One of the problems is that code analyzers, bundlers, compilers (like Rust compiler) allow running arbitrary code without any warning.

Imagine following case: an attacker pretending to represent a company sends you a repository as a test task before the interview. You run something like "npm install" or run Rust compiler, and your computer is controlled by an attacker now.

Or imagine how one coworker's machine gets hacked, the malicious code is written into a repository and whole G, F or A is now owned by foreign hackers. All thanks to npm and Rust compiler.

Maybe those tools should explicitly confirm executing every external command (with caching allowed commands list in order to not ask again). And maybe Linux should provide an easy to use and safe sandbox for developers. Currently I have to make sandboxes from scratch myself.

Also in maybe cases you don't need the ability to run external code, for example, to install a JS package all you need to do is to download files.

Also this is an indication why it is a bad idea to use environment variables for secrets and configuration. Whoever wrote "12 points app" doesn't know that there are command-line switches and configuration files for this.

gpm 6 days ago

> compilers (like Rust compiler) allow running arbitrary code without any warning.

It's safe to assume that the Rust compiler (like any compiler built on top of LLVM) has arbitrary code execution vulnerabilities, but as an intended feature I think this only exists in cargo, the popular/official build system, not rustc, the compiler.

Reply View 8 replies
  • codedokode 6 days ago

    Rust has "procedural macros" which means executing arbitrary code during compilation: https://doc.rust-lang.org/reference/procedural-macros.html

    Reply View 2 replies
    • Philpax 6 days ago

      It can invoke procedural macros, but those macros need to be built by something, and rustc won't do that by itself: https://blog.jetbrains.com/rust/2022/07/07/procedural-macros...

      I still think it's very not good that proc macros have full access to your system, but `rustc` alone cannot build a hostile macro as part of building some code that depends upon it.

      Reply View 0 replies
    • gpm 6 days ago

      Eh, rust has procedural macros, which means executing pre-built plugins during compilation. You can't execute arbitrary code, because you can't make and then execute new macros, you can only run the macros made available to you via the filesystem.

      Admittedly that's a bit like saying "a simple shell isn't arbitrary code execution"... except there tend to be binaries lying around on the filesystem which do things, unlike procedural macros.

      Reply View 0 replies
  • shakna 6 days ago

    Any language that supports constexpr, like Rust's const fn [0], can execute arbitrary code at compile time.

    [0] https://github.com/rust-lang/rust/issues/57563

    Reply View 4 replies
    • gpm 6 days ago

      Rust's const fns run in a restricted interpreter that does not allow for things like non-determinism, syscalls, unsound behavior, etc. They can neither read from nor write to "the environment" in any meaningful way. They don't even expose things like the host's pointer-size to the code being run.

      Reply View 3 replies
      • athrowaway3z 6 days ago

        That's all interesting about const fns, but AFAIK any dependency can add a build.rs that executes anything - and is usually automatically executed by the language server doing a build on Cargo.toml file change.

        Not a Rust-only problem, but one that people should be aware of in general.

        Reply View 0 replies
      • shakna 5 days ago

        Whilst it is restricted, you're not correct that it can't do unsound behaviour and can't do syscalls, and can't do non-determinism.

        It can call unsafe blocks. They are more limited unsafe blocks, but they are still unsafe blocks.

        Reply View 1 reply
        • gpm 5 days ago

          I'm pretty sure I'm not, but feel free to make an actual demonstration to the contrary...

          Unsafe blocks doesn't imply access to undefined behavior, merely the ability to write code that would be undefined in the regular non-const execution model.

          Reply View 0 replies
criemen 6 days ago

> Maybe those tools should explicitly confirm executing every external command

This wouldn't work - it's not external commands that's the problem, it's arbitrary code that's being executed. That code has access to all regular system APIs/syscalls, so there's no way of explicitly confirming external commands.

Python/pip suffers the same problem btw, so I think that ship has sailed.

Reply View 2 replies
  • codedokode 6 days ago

    Then explicitly confirming running every hook with displaying module and function name.

    > Python/pip suffers the same problem btw, so I think that ship has sailed.

    If I ever find time to write a package manager for C, it won't support hooks.

    Reply View 0 replies
morgante 6 days ago

You should treat running a code analyzer/builder/linter against a codebase as being no safer than running that codebase itself.

Reply View 0 replies
raggi 6 days ago

I love this implication that there's some valuable body of code out there that gets reviewed, compiled and never executed.

Reply View 2 replies
  • jeremyjh 6 days ago

    They are talking about executing code at compile time (macros and such). With modern IDEs/editors, just opening the folder may trigger such behavior (when LSP boots and compiles) though some environments warn you.

    Reply View 1 reply
    • raggi 5 days ago

      I know, but the _implication_ is that it's extremely unsafe, I don't buy the implication - code gets executed.

      Reply View 0 replies
jeremyjh 6 days ago

> Whoever wrote "12 points app" doesn't know that there are command-line switches and configuration files for this.

That would mean all those values are in the clear in the process table. You couldn’t do a “ps” without exposing them.

Reply View 1 reply