4 ms·

"curl ... | bash" makes me run away from a project. There is the reductive argument that basically everything you download is arbitrary code, but throwing away

"curl ... | bash" makes me run away from a project. There is the reductive argument that basically everything you download is arbitrary code, but throwing away the code that is run seems uniquely silly. https://news.ycombinator.com/item?id=21490151 https://news.ycombinator.com/item?id=21490151

avz 2y ago
Agreed. Perhaps the most prominent example of this shameful behavior is this one: curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs https://sh.rustup.rs | sh Source: https://www.rust-lang.org/tools/install https://www.rust-lang.org/tools/install
- hulitu 2y ago
  Haha. This is the most secure part. When you start compiling, rust will happily download random "crates" and include them in your program, because "dependencies".
chowells 2y ago
"curl | bash" is the exact same threat vector as "download this compiled installer". I wonder why that doesn't result in the same hyperbolic responses.
- josephcsible 2y ago
  The difference is that "curl | bash" doesn't save the output and can be distinguished server-side from commands that do <https://news.ycombinator.com/item?id=34145799 https://news.ycombinator.com/item?id=34145799>, so it's an especially easy way for a malicious server to undetectably have you run something different from what you've looked over.
  - chowells 2y ago
    So you're saying it's exactly the same as binary installers, which frequently download additional components during installation?
    - josephcsible 2y ago
      When binary installers download additional components, they usually do so in a way indistinguishable server-side from downloading a file to analyze.
      - chowells 2y ago
        Honest ones, sure. Why would a malicious one leave behind evidence of its malicious behavior? The threat model is identical.
        josephcsible 2y ago
        But that behavior would be noticeable in the original download, which would be evidence itself.
blacksmith_tb 2y ago
Pipe to bash install approaches at least can just be snagged with wget to inspect the script without running it, lots of package managers seem harder than that to inspect/predict? Not that there couldn't be sneaky things you'd miss, but at least obvious ones might be detectable...
fragmede 2y ago
alright, do curl | tee saved.sh | sh then
- lxgr 2y ago
  Good idea, unless the attacker serves you just more code that fetches and executes a one-off script from memory (and the download link for that is dynamic and only valid once).
  - fragmede 2y ago
    we could go down a rabbit hole of various exploits and defenses, but at end of the day it all comes down to trust. If you don't trust the source of the code, it doesn't matter if it comes in via curl or a .deb signed with GPG, you're still trying to run untrusted code. If your threat model is such that you don't want to do that, don't do that. No one's forcing anybody to run curl | sudo bash at gunpoint.

avz 2y ago

Agreed. Perhaps the most prominent example of this shameful behavior is this one: curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs https://sh.rustup.rs | sh Source: https://www.rust-lang.org/tools/install https://www.rust-lang.org/tools/install

hulitu 2y ago
Haha. This is the most secure part. When you start compiling, rust will happily download random "crates" and include them in your program, because "dependencies".

chowells 2y ago

"curl | bash" is the exact same threat vector as "download this compiled installer". I wonder why that doesn't result in the same hyperbolic responses.

josephcsible 2y ago
The difference is that "curl | bash" doesn't save the output and can be distinguished server-side from commands that do <https://news.ycombinator.com/item?id=34145799 https://news.ycombinator.com/item?id=34145799>, so it's an especially easy way for a malicious server to undetectably have you run something different from what you've looked over.
- chowells 2y ago
  So you're saying it's exactly the same as binary installers, which frequently download additional components during installation?
  - josephcsible 2y ago
    When binary installers download additional components, they usually do so in a way indistinguishable server-side from downloading a file to analyze.
    - chowells 2y ago
      Honest ones, sure. Why would a malicious one leave behind evidence of its malicious behavior? The threat model is identical.
      - josephcsible 2y ago
        But that behavior would be noticeable in the original download, which would be evidence itself.

blacksmith_tb 2y ago

Pipe to bash install approaches at least can just be snagged with wget to inspect the script without running it, lots of package managers seem harder than that to inspect/predict? Not that there couldn't be sneaky things you'd miss, but at least obvious ones might be detectable...

fragmede 2y ago

alright, do curl | tee saved.sh | sh then

lxgr 2y ago
Good idea, unless the attacker serves you just more code that fetches and executes a one-off script from memory (and the download link for that is dynamic and only valid once).
- fragmede 2y ago
  we could go down a rabbit hole of various exploits and defenses, but at end of the day it all comes down to trust. If you don't trust the source of the code, it doesn't matter if it comes in via curl or a .deb signed with GPG, you're still trying to run untrusted code. If your threat model is such that you don't want to do that, don't do that. No one's forcing anybody to run curl | sudo bash at gunpoint.