4 ms·

hopefully nobody adds a cargo-buidl package then!

by cozzyd 4y ago

nindalf 4y ago
Why would a user install a cargo-buidl package when cargo build already works? Typosquatting is definitely an issue, but not in this specific case.
- kzrdude 4y ago
  The binary can be named that without the package being named so, so it seems it could happen
  - dmytrish 4y ago
    If an intruder can rename files in your $PATH, the defense is already broken (e.g. they could do the same with any of .bashrc, .profile, anything in .local/bin and many, many other places). If a program can run seemingly innocent programs like less or sed, it already can run arbitrary commands. Security story of developing on Linux is basically non-existent unless you do everything on a remote machine or at least in a container (and, oh irony: direct access from your user to the Docker daemon basically means having root for that user).
    - deleted 4y ago
      [deleted]
    - kzrdude 4y ago
      Well I was thinking that "cargo install foo" can already install cargo-buidl in your path by innocent means i.e. no Rust build script. But with build scripts (build.rs) any crate indeed has arbitrary code execution at build time, so they can't be trusted, like you imply. However, sandboxing might be coming for build scripts, and when that's done, the typo attack is still there (package "foo" installing cargo-buidl).
- cozzyd 4y ago
  right, but cargo-buidl could be installed as part of a different package that also provides a more useful-sounding binary, no?
royjacobs 4y ago
You need to explicitly install these tools, so you can't "accidentally" invoke cargo-buidl from a transitive dependency or anything. It's not like a tool like npx which will allow you to invoke code in arbitrary packages.
- cozzyd 4y ago
  yeah it's great that "cargo buidl" doesn't automatically try to download and install cargo-buidl but if cargo-buidl somehow ends up in your $PATH (perhaps installed as a side effect of another package or even some other package manager like pip) then it will run. Though I guess someone could also just as easily put a malicious cargo in your $PATH and that will work in most cases, depending on precedence...

hopefully nobody adds a cargo-buidl package then!

by cozzyd 4y ago

hopefully nobody adds a cargo-buidl package then!

Why would a user install a cargo-buidl package when cargo build already works? Typosquatting is definitely an issue, but not in this specific case.

kzrdude 4y ago
The binary can be named that without the package being named so, so it seems it could happen
- dmytrish 4y ago
  If an intruder can rename files in your $PATH, the defense is already broken (e.g. they could do the same with any of .bashrc, .profile, anything in .local/bin and many, many other places). If a program can run seemingly innocent programs like less or sed, it already can run arbitrary commands. Security story of developing on Linux is basically non-existent unless you do everything on a remote machine or at least in a container (and, oh irony: direct access from your user to the Docker daemon basically means having root for that user).
  - deleted 4y ago
    [deleted]
  - kzrdude 4y ago
    Well I was thinking that "cargo install foo" can already install cargo-buidl in your path by innocent means i.e. no Rust build script. But with build scripts (build.rs) any crate indeed has arbitrary code execution at build time, so they can't be trusted, like you imply. However, sandboxing might be coming for build scripts, and when that's done, the typo attack is still there (package "foo" installing cargo-buidl).
cozzyd 4y ago
right, but cargo-buidl could be installed as part of a different package that also provides a more useful-sounding binary, no?

royjacobs 4y ago

You need to explicitly install these tools, so you can't "accidentally" invoke cargo-buidl from a transitive dependency or anything. It's not like a tool like npx which will allow you to invoke code in arbitrary packages.

cozzyd 4y ago
yeah it's great that "cargo buidl" doesn't automatically try to download and install cargo-buidl but if cargo-buidl somehow ends up in your $PATH (perhaps installed as a side effect of another package or even some other package manager like pip) then it will run. Though I guess someone could also just as easily put a malicious cargo in your $PATH and that will work in most cases, depending on precedence...