5 ms·

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

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.

criemen 1y 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.
- codedokode 1y 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.
- Philpax 1y ago
  Rust is investigating using sandboxed WASM for proc macros, but it'll be some time before there's any movement there: https://github.com/rust-lang/compiler-team/issues/876 https://github.com/rust-lang/compiler-team/issues/876
gpm 1y 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.
- codedokode 1y ago
  Rust has "procedural macros" which means executing arbitrary code during compilation: https://doc.rust-lang.org/reference/procedural-macros.html https://doc.rust-lang.org/reference/procedural-macros.html
  - gpm 1y 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.
  - Philpax 1y 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-under-the-hood-part-ii/ 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.
- shakna 1y 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 https://github.com/rust-lang/rust/issues/57563
jeremyjh 1y 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.
- codedokode 1y ago
  You can also store settings in configuration files.
raggi 1y ago
I love this implication that there's some valuable body of code out there that gets reviewed, compiled and never executed.
- jeremyjh 1y 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.
  - raggi 1y ago
    I know, but the _implication_ is that it's extremely unsafe, I don't buy the implication - code gets executed.
morgante 1y ago
You should treat running a code analyzer/builder/linter against a codebase as being no safer than running that codebase itself.

criemen 1y 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.

codedokode 1y 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.
Philpax 1y ago
Rust is investigating using sandboxed WASM for proc macros, but it'll be some time before there's any movement there: https://github.com/rust-lang/compiler-team/issues/876 https://github.com/rust-lang/compiler-team/issues/876

gpm 1y 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.

codedokode 1y ago
Rust has "procedural macros" which means executing arbitrary code during compilation: https://doc.rust-lang.org/reference/procedural-macros.html https://doc.rust-lang.org/reference/procedural-macros.html
- gpm 1y 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.
- Philpax 1y 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-under-the-hood-part-ii/ 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.
shakna 1y 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 https://github.com/rust-lang/rust/issues/57563

jeremyjh 1y 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.

codedokode 1y ago
You can also store settings in configuration files.

raggi 1y ago

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

jeremyjh 1y 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.
- raggi 1y ago
  I know, but the _implication_ is that it's extremely unsafe, I don't buy the implication - code gets executed.

morgante 1y ago

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